Application: User Account Access Security Analysis for Wallets

[Arsalaan-Alam]

Project Abstract

This application is in response to the RFP: User Account Access Security Analysis for Wallets. This proposal outlines a comprehensive security analysis of popular Polkadot wallets (Polkadot-JS Browser Extension, Parity Signer, Talisman, etc) aiming to fortify the gateway to user assets and foster a more safe and user-friendly ecosystem.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or Polkadot (USDC & USDT) address in the application).
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[Arsalaan-Alam]

I have read and hereby sign the Contributor License Agreement.

[ronykris]

I have read and hereby sign the Contributor License Agreement.

[PieWol]

Hey @Arsalaan-Alam thanks for your application,
to finish the application and make it eligible for review you need to fill out the legal section. For an application to be approved we need you to state a registered address and a registered legal entity. If you don't want to share this information publicly you can also send it to us in an email.

As you seem to not use the referral program please just remove it from the application to keep it concise.

[Arsalaan-Alam]

Hey Piet. Thanks for pointing these changes out. I have shared the registered address & registered legal entity privately through email. I've also removed the Referral section from the proposal.

[PieWol]

Awesome, thanks for the changes and the email. The application is now ready for review.

[Arsalaan-Alam]

Great. We're waiting for the reviews

[Noc2]

Thanks a lot for the application. I have one initial question: have you done a similar analysis before, and in general, what is your experience in this field? I will also share the application with @bhargavbh for additional feedback.

[Arsalaan-Alam]

Hi Noc, thanks for the comment. We've been in the web3 ecosystem for a while. We have used and built across all the major chains and interacted with over 20 wallets. This provides us with enough context about wallets. We have in-depth knowledge of how wallets work, existing recovery mechanisms, access-control techniques, and have also encountered losses / lockouts ourselves.

Apart from this we have technical experience in cybersecurity research in the form of penetration tests and participation in responsible vulnerability disclosure programs. We've built fuzzers and wrote other automation code to test protocols. Previously, we've also built an oracle service that guarantees fully confidential transactions and information retrieval.

Also, in his profession, Krish has experience with securing and analysing data storage solutions. He has been working as a software engineer for the past 20 years, and has a lot of experience in web3 & privacy research.

[bhargavbh]

Hi team! Can you please address the points i raised?

When coming up with this RFP, the idea was to float it as a thesis topic for a BS/MS student or an intern. Ideally, this work should be publishable in security conferences like SACMAT/ CCS/ SOUPS, where the novelty is extending UAAG models for a more Blockchain wallet specific application scenario.
Your proposal seems to have a more applied flavour and not really touching on extension of the models to handle features like multi-sigs and proxies. Would you have the interest and research background to work on such an extension?
If not, as it stands, i suggest collapsing M2, and things like UAAG models and code for analysis should be part of M1. Two FTEs would be an overkill and not the best usage of resources. I suggest revisiting the roadmap and lowering it.

[bhargavbh]

Can you elaborate what tools you plan to use for discovering vulnerabilities and also describe what class of vulnerabilities you plan to target?

[Arsalaan-Alam]

please view the latest commit. (these vulnerabilities are now out of the scope of analysis for this project)

[bhargavbh]

Are these vulnerabilities at the network level? Could you provide some concrete examples of properties you would be investigating?

[Arsalaan-Alam]

please view the latest commit. (these vulnerabilities are now out of the scope of analysis for this project)

[bhargavbh]

How will you have access to server-side logs?

[Arsalaan-Alam]

please view the latest commit. (the server-side analysis is now out of the scope of analysis for this project)

[bhargavbh]

it seems that there is a significant overlap between the first and second milestones. IMO, finding a vulnerability with a clear counterexample demonstrating it is sufficient (which is covered in M1). The wallet team would be in a better situation to patch it, since they have an more comprehensive overview of the architecture.

[Arsalaan-Alam]

updated in the latest commit. only one milestone exists now

[bhargavbh]

I would assume that the analysis report in M1 already includes the models, as it is a pre-requisite

[Arsalaan-Alam]

agreed.

[bhargavbh]

do you plan to use the tool developed by the authors of the UAAG paper or build a new tool? If yes, can you elaborate the need?

[Arsalaan-Alam]

we will just be extending the techniques described in the UAAG paper. There is a very minimal chance that we might discover more formalizing or analyzing techniques, and if we do discover, we will make those techniques public.

[Arsalaan-Alam]

Hi team! Can you please address the points i raised?

When coming up with this RFP, the idea was to float it as a thesis topic for a BS/MS student or an intern. Ideally, this work should be publishable in security conferences like SACMAT/ CCS/ SOUPS, where the novelty is extending UAAG models for a more Blockchain wallet specific application scenario. Your proposal seems to have a more applied flavour and not really touching on extension of the models to handle features like multi-sigs and proxies. Would you have the interest and research background to work on such an extension? If not, as it stands, i suggest collapsing M2, and things like UAAG models and code for analysis should be part of M1. Two FTEs would be an overkill and not the best usage of resources. I suggest revisiting the roadmap and lowering it.

Hi, sorry for the late reply

I went through all of your comments and request some clarifications before I go and edit the proposal. According to your comments, I think we have 2 ways to proceed further.

The first way ahead is that we complete the whole project in an academic setting and submit it at some security conference like SACMAT. We start by sampling the techniques written in the UAAG paper and build upon them to analyze the security of popular polkadot wallets (Polkadot JS, Talisman, Subkey). Using UAAGs we specifically model account generation, access and backup. After this, we do security analysis of complex polkadot features like multi-sig & proxies. We will complete this in 1 milestone

The second way is an applied and more elaborate version of the RFP. We use techniques described in the UAAG paper to formally model the required aspects, but we also go a step ahead and do more analysis of all components from a security POV (UI, implementations, protocols, server-side), after that we could also come up with suggestions to improve security of the wallets. However you pointed out this could be redundant as the wallet teams would have a better idea on how to do it. This way would also take more time to complete.

I couldn't make out from the conversation that which way do you prefer we follow? After researching a bit more, my team is also biased towards the first way. For some more context, this research project would also serve as the bachelor thesis of Arsalaan Alam who is studying computer science at Plaksha University, India. Arsalaan is a full stack web3 developer, programmer, cybersec enthusiast & also aspires to get into academia. Arsalaan has been building & contributing to projects in web3 for the last 3 years. He has participated in over 30 hackathons and won 20 of them.

So if you could please tell us what way does the web3f team prefers we go after. If it's #1, we will refactor our proposal to fit the requirements for #1 (remove milestone 2, shift some tasks from M2 to M1, remove some tasks from M1, lower the price). If it's #2, we'll provide more details on what our methodologies for the extended part of the research would be (info on the new tools we come up with)

looking forward to hear!

[bhargavbh]

Discussion is being continued on Elements channel.

[Arsalaan-Alam]

Hi Bhargav, We have refactored our proposal according to the #1 approach as discussed in the previous comment. There is just one milestone now and the output of the project would be a Research Paper in which we will extend UAAGs to formally model account generation, access control, and backup/recovery mechanisms. We'll also write an analysis report that'll discuss possibilities of unauthorized access, lockout risks & redundancies in authentication.

Please go through our latest commit, we have also brought down the price & reduced the FTE because the scope of analysis has been reduced.

[Noc2]

Hi. Thanks again for the application and all the effort you put into this. However, the grants committee decided not to go ahead with it. We internally discussed it, and it is tricky to structure a grant with a research paper as a deliverable. There is no objective way to evaluate a research paper other than setting the bar to be accepted at a top journal/conference. However, it is too strict a requirement from the perspective of grantees, as the process of getting papers accepted at conferences can be extremely time-consuming. Mere submission of a paper can not be considered a deliverable.
Additionally, we feel the team lacks the required research and paper writing experience for the project. Independent of this, we wish you all the best and feel free to apply again.