Porting these questions and @boris @benjaminbollen answers here from Filecoin Slack. Thanks Eva for great questions!
1) Is the idea of this to have ephemeral cosigners?
- Having actual FIL + access to my data stored on Filecoin tied to a browser cache feels really risky for users.
- (I cleared everything in my browser cache the other day just for housekeeping.)
- Is the target use case mainly for small / temporal use? Filecoin deals for cold storage may have a lifespan of 6 months to a year.
- Do you intend to add more long-term key management solutions later on or are co-signers intended to be coupled with existing ones?
- Ephemeral co-signers may make more sense for use cases like sharing a file one-time for example or token-based access.
Currently you have to trust the keys attached to Lotus. We’re focused on making this better with keys in the browser which sounds scary but sits on top of a secure stack, PLUS the co-signing. Our entire system is long term key management using WebCrypto.
On ephemeral data: it’s not ephemeral. web native accounts are linked per device / browser. We encourage people to link multiple devices. The file system is stored and backed up encrypted on IPFS by Fission. You can re-link from any device.
We are working on account recovery also using the co-signer scheme to restore access without fission holding keys in case of losing access to all devices.
Follow up: But the browser is not a logical place for long-term key management? It’s recommended to clear your browser cache regularly. Linking to a browser cache on a phone doesn’t really secure a long-term backup.
You can think of it as a per app key if you like, but it’s not ephemeral, just like all of Fission’s webnative.
It can get cleared on a browser / device but it persists in our encrypted file system.
Fission’s entire account system is built on this and it is has been working quite successfully so far.
This is exactly what we proposed we were going to do in the grant – make Filecoin work in a browser, without browser extensions, including on mobile
Also, now that I think of it, probably useful to point out that we generate a new key on behalf of the user in the app
2) Is hosting this as a service in your team’s roadmap?
hosting which parts? The software is an app, yes we’ll host it.
The co-signer is necessary, we’re building it so it is very easy to host, one click deploy to Heroku. You also need to run the entire Powergate stack.
We see this as a building block where any Powergate small miner / app dev can run this so users can use it from any web browser.
The goal is to get native Filecoin in browser for apps devs. Easy enough for app devs or miners to host. As trustless as we can make it with the current Lotus setup. We can make recommendations on Lotus account abstraction to improve this.
3) Will you be getting UCAN security audited eventually / feedback from other external cryptographers?
UCAN doesn’t use novel cryptography, it’s more about the end to end flow with JWTs. WNFS, which is where the encrypted file system is, is the more cryptographically intense part of the system. Yes we’d love to have a security audit done of the end to end system.
We have several other teams looking at UCAN in different ways. The Planetary team who work on Secure Scuttle Butt (SSB), the Qri team who are on IPFS / data science implemented UCAN in GoLang, and I think Carson from Textile said he was going to take a look.
No obvious flaws are currently known in the spec.
Further answers from @benjaminbollen:
it s good to point out that all data is stored encrypted on IPFS and then duplicated on Fission servers (or anywhere you want to reduantly store it as IPLD trees)
Fission will put on a DNSlink (under alice.fission.name) the root of the entire end-2-end user encrypted filesystem tree of Alice’s data
so the local storage is just a cache of that versioned tree that lives on IPFS, and is kepts by Fission, and with the backup app can be snapshotted onto Filecoin
the second aspect of this is then, where are the RSA keys kept for issuing write permissions with UCAN; and where are the AES keys kept which give read access to the root of the FileSystem, or a specific subdirectory (WNFS builds on Cryptree where each file and directory is encrypted with a random AES key; and read access to a directory gives read access to the underlying children)
these keys (RSA for writing, AES for reading) are kept in localstorage, and RSA keys are shielded from JS code by W3C WebCrypto API, ie. they cannot be exported out of indexedDB
the line of defense of not getting locked out from your filesystem here, is twofold:
- implemented: multiple devices. ie. the first device you create a Fission account is (arbitrarily) the origin did. Once you have a Fission account, you can go to another device, and link with (any of) your already authorized devices; what happens is that a “full delegation of all future permissions” is granted from the first device to the newly linked device. It also securely shares the root AES key to the new device. specification here Whitepaper – Fission. You can also link your account to a desktop executable / CLI atm, which would not get purged by the browser - this does not cover most non-developer users though, but developers naturally start with Fission cli to build serverless apps on Fission/IPFS
- secondly, as part of the work in this project, is account recovery. There are many ways one can balance the trade-offs for users that have lost all devices. And a lot can be tuned for requirements of different apps and their audience. Here we chose for now to guarantee it is fully non-custodial; ie. Fission can in no way “break into your filesystem and Filecoin wallet”.
with recovery we want to solve for the most difficult case where a user only has a single computing device (ie. a smart phone). In the recovery flow laid out, the user has to back up a “recovery code”, which can be done progressively, ie. users can start on the browser and then be prompted to store the recovery code, eg automatically on their Apple cloud storage when downloading from safari. details of the recovery flow here Whitepaper – Fission
Is the target use case mainly for small / temporal use? Filecoin deals for cold storage may have a lifespan of 6 months to a year
you also asked this question, so Fission webnative Filesystem (WNFS) is definitely architected to be persisted; it is an append-only versioned tree; so snapshotting it to Filecoin is a natural fit
it s effectively a Modified Merkle-Patricia Tree (MMPT), meets Cryptree (hierarchical R/W ACL), meets fully anonymised metadata by storing files under obfuscated keys in the MMPT
what we build in under this grant is a trustless service that connects Filecoin (Lotus impl + Powergate to manage deal renewal and restoration) on the one hand, with a non-custodial, encrypted IPLD filesystem natively in the browser on the other end;
the challenge we cryptographically have solved for that, is how to use the RSA cryptography standard for Json web tokens to delegate permissions on the web, with secp/bls12-381 cryptography that governs ACL permissions on Filecoin (or other bc networks)
and that’s where a cosigner comes in (which is not ephemeral to be clear)
by aggregating two BLS signatures (one signed by the user, and one signed by the cosigner IFF presented with explicit JWT from user with valid RSA signature chain to the origin did for that account, requesting the cosigner to cosign this explicit message)
this JWT chain, is explicitly conforming to JWT as used prolifically on the web, and the RSA signatures are protected by the W3C WebCrypto standard which has been fully implemented by all major browsers on all platforms (mobile and desktop)
so it is really important to emphasise this point that the architecture is
- fully compliant JWT best-practices
- permissions governed only by RSA signatures using W3C standard as implemented by the browsers
- to then sign BLS12-381 aggregate signatures as adopted by Filecoin itself
I’m super happy to explain this more, and differently and obviously we already have and will keep inviting reviews of qualified security experts in the community, and we develop everything in the open and documented