Create Interstellar-Network.md

[nashjl]

Project Abstract

Interstellar is a novel non-custodial peace of mind mobile wallet with a hardware security level. Based on a Substrate blockchain and SubstraTEE/IntegriTEE workers.

We can now provide the same hardware security level as hardware wallets with only a mobile and a blockchain.

For which grant level are you applying?

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

Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
• I have read and acknowledged the terms and conditions.
• 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.

[CLAassistant]

All committers have signed the CLA.

[semuelle]

Thank you for your application, @nashjl! We will look into it as soon as possible.

[Noc2]

That sounds like an interesting project. I just shared your application internally. But I already have two questions: What are potential attack vectors of your solution? For example what happens if TEEs are exploited? Do you already have any mock-ups or designs for your wallet?

[nashjl]

That sounds like an interesting project. I just shared your application internally. But I already have two questions: What are potential attack vectors of your solution? For example what happens if TEEs are exploited? Do you already have any mock-ups or designs for your wallet?

Hi David, thanks for your message.

Potential attack vectors of the solution are mainly banking trojans with overlay capabilities on a rooted device. You can check this medium article: Are Cryptocurrency Wallets more at risk than ever?

To address potential exploits/flaws in TEE and especially in Trusted User Interface but also because TUI i.e., Hardware Protected Confirmation is not yet available on all devices:

We have designed a transaction validation screen, based on a One-Time Garbled Circuit that ensures computation privacy and displays Visual Cryptography shares/ frames, that is screenshot proof. More importantly this scheme makes the design of a fake UI overly complex and costly for an attacker. So, the scheme can address current state of the art banking trojan threat but not yet a targeted attack. More information is provided in Detailed Documentation in the Project Details section.

To address the later threat, we are working on a malware detection scheme also based on garbled circuit, but this still is an ongoing research effort.

To address potential exploits on TEE/IntelSGX on the nodes, we have also planned to develop an SMPC/TSS layer and at a later stage a full HSM layer 2 based on YubiHSM. See the Future Plans section.

Mock-ups of the wallet are available on our website Interstellar

[Lederstrumpf]

Hi @nashjl,

Thanks for your application! This is potentially very interesting.
I want to try out your garbled circuit implementation to assess whether this is a viable stepping stone towards a later integration of TUI (and perhaps mitigation of any security holes it will inevitably exhibit).
Can you share a link? I couldn't find any here.

I tried https://cseweb.ucsd.edu/groups/justgarble/, but its Makefile is severely outdated / underspecified, and I eventually realized it's pointless to get it working if you already have a running version with significant changes catering for the use case described here.

[nashjl]

Hi Robert, thanks for your message and interest.

The JustGarble modified version is intricately linked with the rest of our core code in the whole pipeline. This garble circuit generation part was not meant to be used independently with a cli (e.g., using user-specified file as input) due to the performance optimizations we developed. Consequently, we cannot provide you immediately with a cli based on our library to garble an example logic circuit file outside of our pipeline.

Providing you with the whole package could also be a bit tricky for us now. We cannot easily distribute it as-is because this is licensed under GPL. More importantly, it will also be complex to use as it is poorly documented for now. Especially knowing that the goal of the Substrate OCW GCF project part is to provide a friendly API and the related documentation to use it.

However, our JustGarble modified library is extremely close to TinyGarble that is also based on JustGarble with both Free XOR and HalfGate enhancements. We even considered using it to replace the JustGarble part that is no more maintained.

So, I would suggest you test TinyGarble as an alternative and we could use it as a reference implementation.
https://github.com/esonghori/TinyGarble. It looks like It compiles fine on Ubuntu.

Does it work for you?

[nashjl]

Hi @Lederstrumpf,

We are very motivated by the opportunity to work with Substrate within the W3F/ Polkadot/Kusama ecosystem.
So, we can provide you with our worker code right now if you are still interested in it BUT:

• it is licensed under GPL(it will not contaminate the substrate code b/c the OCW will be exposed through an API)
• it is not yet fully documented
• it was meant to be specific to our pipeline, i.e., it cannot yet use user-given verilog input

Please let us know and we will provide you with a link to our repository that also include the design of our circuits.

[Lederstrumpf]

hi @nashjl, apologies for the delayed response.

Please let us know and we will provide you with a link to our repository that also include the design of our circuits.

Yes thanks, that will be useful for assessing this application.

it is licensed under GPL(it will not contaminate the substrate code b/c the OCW will be exposed through an API)

Noted - that will be fine then.

[nashjl]

Hi @Lederstrumpf,

Following the link https://github.com/Interstellar-Network/lib_server on our repository, feel free to come back to us if you need any kind of assistance.

We are currently working on an accurate simulation of our transaction screen for multiple screen frequencies based on https://www.psychopy.org/ (used for neuroscience/psychophysics research experiments).

The simulation links will be ready and posted in the upcoming days.

[nashjl]

Hi @Lederstrumpf,

Here is a link on our Transaction validation screen simulations based on PsychoJS library - PsychoPy (github.com)
It works well on chromium-based browsers, chrome, brave, edge but not on firefox.

We also added it in Detailed documentation.

Best wishes for 2022 to you and the W3F team !

[Lederstrumpf]

Hi @nashjl, thank you for the links!

With regards to the transaction screen, does this actually mitigate a material class of attacks? Essentially, if an attacker can already take screenshots of my device, shouldn't they also be able to take sufficient of these to add up & reconstruct what the "visual cryptography" was supposed to obfuscate? Especially since it doesn't seem that they have to capture successive frames to reconstruct - just 3 distinct ones (for the 60Hz scenario), unless you randomize the digit slicing.

Quoting from your Detailed documentation (which I lack rights for commenting on directly):
"However, it makes a fake UI attack, complexe and resource intensive enough to enable us to detect it during the transaction validation session."
what's the increased cost in a fake UI attack? Having to also use https://github.com/psychopy/psychojs or similar, in lieu of just having a static interface?

But I'm also (luckily!) not too familiar with today's banking trojans, so maybe I'm just missing it ;)

[nashjl]

Hi @Lederstrumpf, thanks for your comments and questions.

1/The simulations demonstrate the look and feel of the display for different frequencies. Our garbled circuits are designed to manage:

• randomize slicing of the digits, 1/n segments/sub segments per frames, with n > 2
• the addition of pixel-based and/or segment-based patterns at a later stage as well as decoy-frames.

2/ Yes, the dynamic interface itself drastically increases the cost of an attack, but such type of fake UI (even if the bad actor succeeds to get enough frames quickly enough) will also require an overly complex synchronization to build and display a dynamic overlay with fake informations while preserving the look and feel the user is familiar with (which makes the attack even more expensive and time consuming)

Following is a potential approach Extract of one of our draft papers/previous research that leverages both SRAM/DRAM speed difference and iconic memory/visible persistence properties to show that a pixel based visual cryptography with pixel expansion scheme won’t let an attacker acquire more than 4 pixels on 1000 pixels written on the framebuffer for image recognition.

Such approach and others will be combined with the malware detection scheme we are working on to achieve targeted attack protection on top of TUI.

3/At this stage, and without TUI, our solution resists a generic state of the art banking trojan. Because even if one could capture screenshots, it would still need some processing after to attempt the digits recognition; or even possibly a human intervention to read the screen. Then, the tentative to build a fake UI will require a unique effort specific to the user and device.

Bad actors 'organizations are business oriented and are looking for the best ROI. Consequently, hackers are pragmatic people and focus on the weakest prey when they face unexpected complex issues that are costly to overcome.
We aim at being as pragmatic as the threat actors and update the security based on threat probabilities, considering the overall security of other solutions. The cost/benefits to try to develop an attack would realistically mean hackers would target more profitable preys.

Rather than focusing on an overkill solution for the current threat landscape which could negatively impact the user experience on low end devices, we prioritize a highly secure scheme with a healthy UX/Security balance.

There will always be research efforts in parallel to match the threat increase when required.

Our strategy is to be the strongest/quickest😅 prey with the easiest solution. for the user.

---

-PS: send us your email to [email protected] to comment the doc.

[Noc2]

@nashjl One additional question came up internally: Is Eliot Leleu actually working at parity, because this doesn't seem to be the case? (see https://www.linkedin.com/in/eliotjfl/) Could you clarify this?

[nashjl]

@nashjl One additional question came up internally: Is Eliot Leleu actually working at parity, because this doesn't seem to be the cae? (see https://www.linkedin.com/in/eliotjfl/) Could you clarify this?

Hi @Noc2, thanks for pointing this out. No, he is not working at Parity. This is due to improper handling, a mishandling in the setting of his profile. I assume he wanted to show that he is working with Parity substrate technology. It is now corrected, and we apologize for the inconvenience.

[Noc2]

Thanks for the update. I’m happy to support this application and will mark it as ready for review, so that others take a look at it as well.

[nashjl]

Thanks for the update. I’m happy to support this application and will mark it as ready for review, so that others take a look at it as well.

Hi @Noc2, thanks a lot for your support!!!!

[alxs]

@nashjl you introduce the project as being a wallet for the ecosystem to reach mass adoption and mention that you're targeting Dapp developers, but it looks like your wallet can only function in combination with its own dedicated chain. Am I missing something? Also, could you expand on MathWallet's MPC approach and why you deem it 'more expensive, cumbersome to use, less flexible and more complex to deploy' than your solution?

[nashjl]

Hi @alxs, thanks for making us clarify and articulate our positioning and value proposition with your questions.

Yes, our wallet can only function in combination with its own dedicated chain to expose multi-chain wallet features to users and developers.

We think that a friendly wallet user experience and especially a simple wallet set-up is crucial to support the ecosystem in reaching mass market adoption.

We will target Dapp developers from multiple blockchains by helping them integrate our wallet solution with only a few lines of code. This will help Dapps to onboard non-blockchain people as they don’t have to be familiar with the blockchain tools/wallet set-up processes, nor have any technical knowledge to begin with.

In this respect, we are observing that wallets based on simple login/password/web2 authentication (users are familiar with) like Fortmatic , Portis , Torus etc... are showing a strong traction and growing adoption rate - especially in the DeFi space.

We aim at competing with those solutions with the same type of easy integration for Dapp providers/developers.

In addition, those “friendly wallets” show the following issues that we can address with our solution based on a dedicated substrate based blockchain (potentially; parachain/parathread):

• Centralized software: Their privacy and censorship resistance can be challenged because they rely on major player cloud infrastructures like Google, FB, Amazon and especially their Web 2 Auth like OAuth compared to our frictionless and more secure Decentralized Transaction Validation Protocol.

• Trust issues: They are operated by private companies the user needs to trust. In addition, their sustainability and future proof can be challenged compared to a blockchain based solution that can rely on a major blockchain like Polkadot.

• Security: They are all very weak on the user side. The Web 2 auth can easily be compromised by malwares and even man in the middle attacks. Because they enable users to set-up 2FA like Google Authenticator or others, it significantly complexifies the user experience without a real security enhancement - The Booming Underground Market for Bots That Steal Your 2FA Codes
  On the backend side, they usually provide enough security for the private keys with MPC (Torus) or HSM (Fortmatic) but have an increased security surface exposure related to their dependence on proprietary cloud infrastructure compared to a blockchain like ours that uses TEEs and SMPC to mitigate TEE potential flaws (and reciprocally).

We think that we can achieve an even higher ease of use and set-up simplicity as those “friendly wallets” with just the download of an app.

Regarding MathWallet, we compare our solution with their future version that is supposed to use smartcards.

Compared to their current version, we can deliver a higher security level and a friendlier user experience as we don’t even need a password nor backup phrase to remember.
We just wanted to underline that the usage of a smartcard is cumbersome and costly for the user as the concept is similar to a classic hardware wallet like ledger and trezor. Additionally, the deployment is much more complex than the download of an app like ours for a comparable level of security. The usage of TEEs (combined with SMPC at a later stage) also enables better tps performances than MPC.

[alxs]

I still don't follow. If your wallet can only function in combination with its own dedicated chain, how do you expect Dapp developers from multiple blockchains to integrate your wallet solution with only a few lines of code?

[nashjl]

We will provide an SDK per blockchain to the Dapp developers.

F(message to sign) -> signed message.

[nashjl]

Regarding the latest attack on Crypto.com, this is the perfect illustration :

• of the weakness of current (2F)Authentication used by crypto-neobanks, CEXs and no-hardware wallets
• that the fraud industry is now focusing on crypto owner accounts and wallets

In addition, it is very likely that wallet owners as well as some other major exchanges are also experiencing such attacks. In our opinion, this issue is underestimated because wallet owners can’t complain and CEXs prefer to hide such issues up till they are obligated to communicate on it, like Crypto.com recently.

We want to underline that this is exactly the type of attacks we can address in a friendly way with our Transaction Validation Protocol/Trusted Authentication and UI layer on mobile.

This event reinforces our opinion that a stronger authentication and security for the front-end/end-user layer will benefit the overall security and user experience of the Polkadot/Kusama ecosystem.

[Lederstrumpf]

Hi @nashjl, thanks for your effort in responding to our repeated queries, and apologies for my delay.

While I'm generally hesitant to support building of tech that's a stepping stone while waiting for greater adoption of a securer standard, I think you've argued well that it's justified in this case, and you've clearly put a lot of solid thought into this, so I'm now happy to support your application :)

My one remaining question is regarding M4.2: what part of the Mobile Registry pallet do you intend to migrate into SubstraTEE/IntegriTEE workers (privkeys + payload signing facilities?)? Or rather, what will you not move into the workers (just external API?)? I'd suggest making this explicit in the milestone description to avoid any issues/misunderstandings with the assigned reviewer later. All other milestones are clearly defined.

I'd also say that 0.e (article/workshop) on every milestone but the last is nice-to-have, but not required if they turn out to be too much work and your documentation is good enough. But if they're useful for community building on your part - all good.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[nashjl]

Hi @Lederstrumpf, thanks a lot for challenging us with pertinent questions, helpful and valuable feedback and especially for supporting our application! :)

Thanks again for asking us to clarify M4.2 to avoid any ambiguities. We will migrate the mobile registry in TEE excluding external API part i.e., access to mobile public(non-sensitive) on chain information (to be detailed during M3 development before M4).

As you mention, the articles on milestone deliveries are a great opportunity for us to start communicating with dev/technical-friendly people.

[nashjl]

Thanks for supporting the application! @gautamdhameja

[nashjl]

Hi @Noc2,we faced unexpected issues regarding the refactoring of our Garbled Circuit Factory, especially related to the usage of up to date versions of Yosys and ABC (used for Verilog circuit generation, synthesis and optimisation). We are working on managing new logical gate types in our blif circuit parser (used to generate our own circuit format .skcd). This should improve the performance of our circuit generation pipeline.

We anticipate a little delay regarding the first M1 delivery. We are currently targeting March 7.

[Noc2]

@nashjl Thanks a lot for the update! A small delay isn’t an issue at all. If it takes longer feel free to create PR and update the application with a new timeline. We only enforce timelines and potentially terminate grants, if we realize teams are no longer working on it and don’t respond to our messages.

[nashjl]

@Noc2 Thanks a lot for your feedback and helpfull information

[nashjl]

Hi @Noc2, almost ready... we will create the delivery PR before the end of the week.

[Noc2]

Sounds good. Thanks for the update.