Multi device risks

[mixmix]

Enjoyed reading this spec a lot.

One thing it would be good to map out, is that if we allow one master key across multiple devices, then do increase our attack/ risk surface a lot.

i.e. if i lost my phone i may have to completely scrap my identity on all devices.

[mixmix]

This may be a reasonable trade off, compared to the cost of complexity of doing anything else, i just want to explore that a little up see to bound the space

[staltz]

Yeah I think it's worth to bring up. Might even put that in a "security considerations" in this spec once the spec is finalized.

I have been shower thinking that it would be good for us to have some way of remotely logging out of those other devices.

Quick sloppy idea: each device could get a "device fingerprint UID", hash it, and make that become some kind of secondary key which also signs each message published. Think msg.value.signature is from the primary key (shared from all devices) and msg.value.subSignature is from the secondary key (device-specific). Then, any device can publish a "log out from tablet" message that will invalidate the secondary key on the tablet device, such that everyone should ignore messages published/signed with that secondary key.

[gpicron]

Following the principle of the Bundle/named backlins/administrative records/anchor administrative records/metafeed hierarchy (but with reverted links with the backlinks) that I proposed in #10 :

We can add an Administrative Record that allow to kill a sub-feed.

In this scheme, the private Master Key, is never stored anywhere. Either it is generated from a long password or user has a "recovery" pass phrase or a printable QR to keep in a safe. Idea is to make it expiring after let say 2 years, and maybe some "proof a work" to generate it to prevent one to be able to generate a lot of Master key rapidly to attack the network. This key is rarely used, most often just for rotating itself every 2 years or to create a sub-master for some application type (here for Social Media). It may use a stronger key pair scheme based on lattice to be more quantum resistant. Anyway this is not frequently used, so who care if the keys and signatures are several KB instead of 256 bits

The Social Media identity feed contains only CRDT data that are easy to merge and the private key can be stored on all devices. (actually, it may be written as a strong encrypted box in the Master Key Feed for easier retrieval). Rotation of key should be more frequent (every 6 months maybe as there should not be so much message in size between 2 anchors)

The Social Media identity is used too to create Device Identity. 1 per device. The private key is stored on the device. Anchor frequency should be driven by the total size of post messages to replicate from the previous anchor and by a maximum lifetime of the key much shorter (every month maybe). Why ? First, the more a key is used, the more it is "attackable". Second, one of the aim of the anchor idea is to give a periodic user driven truncation of the past messages. Third, others can decide that if a anchor with a key rotation was not produce let say 1 month after the expiration, the local replica is garbage collectable. (anyway, if the owner later renew, it has the master copy and can redistribute it), So followers can garbage collect the posts, while continuing to replicate the "previous-feed" relation to previous anchor until the owner eventually renew the key. That will make automatically disappear abandoned account from the network while keeping the possibility to a user to be absent for a long period (let say Dominic cross the Atlantic in his boat during 2 months and is blocked because a pandemic ;-) ).

We can define an additional Administrative Record "Kill" that allow a Identity to remotely kill a sub feed (here in the example the Social Media master Identity kills the Device 2). That instructs others to destroy their replica of the Device 2 feed and the Device 2, when it starts and see that Kill record to self-destroy.

[staltz]

@gpicron Thanks for the diagram and the details, this helps me understand what you meant.

I think both @arj03 and I are ready to drop the concept of metafeeds, and with that also drop multiple keypairs as well as key rotation. This goes into the category of problems that are good to solve, but are not as pressing as other problems which classify as existential or haunting or frustrating. I think there is a simplicity and a straightforwardness to having a single keypair, and this is suitable to casual social networking use cases.