“Why are you look at me like that?” her dad asked.

“Because Mom wouldn’t buy a phone, you would,” Trudy responded.

“Sigh... guilty as charged I suppose,” Dad responded. Mom tried to hide a smile. And with that Dad reached over to the stack of papers and books near the breakfast table and pulled out a white box. Trudy’s eyes lit up. Finally, her own phone!

“Happy 10th birthday” Mom and Dad said together. Trudy grabbed the white box and ripped it open to find a brand new phone. She had a big smile on her face and hugged her Mom and Dad saying “Thank you” over and over again. After turning the phone on Trudy was met with a screen saying “Establish Identity - Upload or Create.”

“What’s establish identity?” Trudy asked her father.

“That just means you need to tell the phone who you are.”

“Do I have an identity already? Maybe from my laptop?”

“No, you don’t, we’ll have to create one for you. Hit the create button.”

With that Trudy hit the create button and was met with a screen that asked for her screen name. Trudy typed in “Trudy” and hit return. The phone then displayed “Mechanism to store Root Key - Print or Save to External Storage”.

“Huh,” Trudy asked, what does that mean?

“It means,” her Dad responded, “that you have to save your root key so if the phone is lost or stolen you can recover your identity. We need to print it and both you and I will keep copies. If your phone is ever hacked it will let us get back control of your phone. But if we lose that paper then you are out of luck because your phone won’t store the root key, just an intermediate key that is signed by the root.”

“Um....”, Trudy said looking more than a little confused, “what?”

“I thought you were taking a basics in computer security class at school?” her Dad responded.

“Not until next semester, it’s just a one semester course.”

“Sigh... o.k. look. Think of it this way. The root key is the ’master key’ for your identity. All the machines you deal with will know you by that key. But it’s too dangerous to keep on your phone. In fact even printing it out isn’t a great idea. I actually keep mine on a special single purpose machine that just stores the keys and generates the intermediate keys and shares them via a USB connection. It has hardened hardware that makes it highly resistant to even physical attacks and I keep it hidden. But your identity isn’t intended for high value purposes and you will certainly want to completely change it when you get older so a print out is fine. That print out is your ’emergency get out of jail’ card. If the phone is lost, stolen, hacked, whatever, you can use that print out to expire your old intermediate key and thus kick that violated hardware out of your system. What the phone is going to do is generate that root key, use it to generate the intermediate key and then print out the root key and forget it. It is only stored in volatile memory and once the key is printed out it will even write over that memory just to be safe.”

“O.k. sure... um... right. So I hit print?” Trudy responded in her usual ’if I don’t encourage him he won’t go on’ tone she used whenever her dad went full geek.

Her Dad, fully realizing he was being humored, responded “Yes, hit it and enter 2 copies.”

“But the phone is asking for a password” Trudy responded.

“Oh yeah, it found the printer but we keep a password on it since we leave the WiFi network open. Give me the phone.” Trudy handed the phone to her father who typed in the printer password. With that two sheets of paper came out of the printer with a QR code that encoded the public and private parts of the root key.

One can imagine that if a workplace insists on providing an employee with a distinct work identity then the work place would have its own master store for root keys for its employees and so the employee wouldn’t have any access to the root key thus leaving the employer with ultimate control over the identity. So while the system can work in a completely distributed way it doesn’t have to. Well talk later about attestations as another way to manage work identities.

“But aren’t a lot of people named Trudy?” his daughter responded.

“Yes, but that’s o.k. It’s just a suggested name to anyone you exchange identities with.”

“Dad, I’m getting sick of saying ’Huh’, could you maybe explain things in something closer to English?”

“Sigh... sure.. Look. Here’s your phone.” With that Dad reached into his pocket and pulled out his own phone. “Now watch.” With that Dad put his phone physically next to Trudy’s. Both phones displayed a dialog saying “NFC connection detected - action?” which was followed by a list of possible actions.

“Now you see where it says ’Exchange Identity’? Hit that button.”

Both Dad and Trudy his the “Exchange Identity” buttons on their phones and both phones displayed a ’Add Identity?’ dialog which asked for a pet name.

“Now this part is really important,” her Dad began. “A pet name is a name that you choose for someone you have exchanged identities with. They can suggest a name, for example, if you look at my phone it says suggested name is Trudy just like your phone says suggested name is Mollari.”

“Mollari?”

“Long story, although you are getting old enough to see it. But another time. For now type in a name that will uniquely identify me.”

With that Dad erased “Trudy” and replaced it with “My lovely daughter” while Trudy erased Mollari and replaced it with “Dad”. Both hit Save.

“But Dad, am I supposed to go bump phones with everyone I want to talk to? Grandma lives far away, we won’t see her for months! How do I talk to her?” Trudy asked.

“Actually that’s the easy part. Watch. I’m going to your entry in the Address Book on my phone and marking you as a member of my ’Friends and Family’ group. Now check your phone. There, in your inbox, see “Accept Group Synch?”. See how it has Dad in bold. That’s really, really important. That bold means the name is a verified pet name. It means that the sender of the message has been verified as the person you gave that name to. All the apps on your phone that have access to your address book will use that rule. If a name is validated it will be in bold otherwise it won’t. So you can trust bold names, not ones that aren’t bold. But in any case if you accept that invite then it means that all entries in my Friends and Family group will be pushed to you. This will give you Mom and Grandma’s information automatically. The update will also prompt you to check the names and make sure you are o.k. with the pet names.”

“But there’s like 30 names here! I don’t want to validate them all!”

“That’s o.k. If you don’t validate the name then it will always show in normal font until you do validate them. But you can see that the phone is showing you that none of the names conflict with any existing pet names, which makes sense since I’m the only person in your address book. So you can just accept them all.”

“But what about Brian?”, Trudy asked, “His family moved and I know he has his own phone, but I don’t know when I’ll see him again and he isn’t one of your friends or family. How do I exchange identities with him?”

“Well, you have been exchanging emails with him? Right?”

“Yeah.”

“And, you’re sure he has established an identity?”

“Yeah.”

“In that case you can do something that isn’t super secure but is fine for you. You can just email him a request. But to make that work we first have to hook up your existing email address to your phone. Go to the email app and add account. Now type in your email server and your email name. Go through the permission delegation dialog. O.k. good. Now your email is connected to your phone. So now go back to your address book and create a new entry, title it Brian and put in his email address. Now hit ’Send identity exchange request’. Put in a note so he’ll reasonably believe its you. O.k. there you go. When Brian’s phone gets the request it will validate that you sent it and if he accepts will send your his identity information and give him yours.”

There are a whole boat load of assumptions in this scenario so I think it’s useful to walk through them.

This scenario assumes that every device has a centralized address book which lists all identities, groups, pet names, etc. It’s assumed that all authorized apps work through that address book. It’s also assumed that this address book is kept in synch between all devices in the user’s mesh. Presumably it uses a last update wins approach for automatic conflict resolution but how sync conflicts are handled can be left to the user. There are lots of other conflict resolution models here including central point of failure (e.g. having one device anointed as the holder of the truth), trying to create a consensus ring (good luck on random devices but if you add in cloud services or distributed hash table services like Freenet it might be workable), etc. The point is, there’s an address book service, all apps hook into it and it’s synchronized amongst all devices.

In this scenario we can assume that Dad’s ’friends and family’ group has its membership viewable to its members, otherwise Trudy wouldn’t have gotten pushed all the new address book entries. This also means that Trudy’s entry in the group will be visible to all the existing members of the group. How this would work is something we’ll address a bit later.

The email exchange mechanism works on the following idea. Trudy’s phone would send Brian’s email address an email with a specially formatted section. Brian’s device (or devices) would receive the email, notice that it contains a formal request for identity exchange and immediately send a challenge to Trudy’s email address. This is meant to prove that the email came from Trudy. Trudy’s phone would see Brian’s challenge which would contain a validation ID from Trudy’s original mail. So Trudy’s device would automatically answer the challenge sending back a confirmation without bothering Trudy. This would provide as secure as email currently can proof that the original request to exchange identities came from Trudy’s email address. At this point Brian would be asked if he wanted to accept the request and if he did he would both receive Trudy’s identity information (e.g. her root public key, proposed Pet Name as well as information described later in this document to find Trudy’s devices) and send similar information directly to Trudy’s device over a point to point connection. How this point to point communication occurred is similar to the previously mentioned group update problem and will be discussed later. Obviously an email based verification mechanism is pretty screaming insecure so it’s only useful in scenarios where one isn’t worried about attacks from state level or other powerful attackers. One can trivially imagine such weakly authenticated mechanisms as being marked differently or perhaps even banned by policy settings on particularly secure devices. Minimally all address book entries would indicate how they were received and validated so various types of auditing and defense are available.

“I’ll set it up but you’re staying here. Don’t worry, this part will be super fast. Please go get your laptop. ” With that Trudy ran to her room to get her laptop once she returned her Dad continued. “O.k. so your OS is already peer to peer web enabled so we just need to set things up. Go to your system settings and choose add to mesh. Now you see that four digit number on your laptop? O.k. get your phone. Go to settings/add device to mesh. O.k. it detected the bluetooth signal from your laptop and knows you want to pair it. Great, now type that four digit number from your laptop into your phone. Great now all your address book information, files, etc. will be automatically synch’d for you. So no set up mess and in the future everything will stay in synch automatically between your phone and your laptop.”

Note that we used Bluetooth in this scenario but since both devices are on the same WiFi network we could have used mDNS.

Also note that even SSL supports mutual auth via symmetric key so the code would never be sent in clear on the wire. This is why something like mDNS could work. If the user picks the wrong device, in theory, no harm is done since the mutual auth will fail and the code won’t be exposed.

Once the devices mutually authenticate the code then the phone would generate a new intermediate key as a child of its intermediate key and hand it to the laptop. This means that the laptop’s key is two levels down but still rooted. In particularly secure scenarios one can imagine that only some devices might have the right to generate intermediate (as opposed to leaf keys which would be used for things like establishing particular connections) keys or possibly no devices can generate an intermediate key and one must always use the root key. What’s allowed would be baked into the policy statements inside the certs.

If one wanted a root key based system then Trudy could have used the QR code on the print out to give the root key to the laptop who could use it to generate its own intermediate key just like the phone. Then, since they are on the same network segment via WiFi, something like mDNS could be used to broadcast identity. The phone and laptop could then use something like mutual SSL auth to prove to each other that they both have a key with the same root and then they could prompt Trudy if she wants to pair the devices together. But I generally thought avoiding the use of the root key is a good thing. The downside to avoiding the root key is that in theory if one knew that just one device had been hacked or otherwise compromised then it would be possible to just revoke that device’s key but in practice it seems likely that a revocation would take the form of the root key revoking all keys issued before some point in time. Well discuss revocation in more detail later.

But a more interesting question is - how do the devices stay in synch as they move around to different networks? This is effectively a rendezvous problem. There are two obvious approaches here and we need to play around a bit with both to see which is best in practice. The simplest approach is probably just a single point of contact. Imagine that all the devices in the mesh agree on a single key that identifies the mesh. All the devices have the private key for the mesh. Then we can use something like Tor’s hidden service where the mesh key is the identifier. Whomever grabs the Tor hidden service registration first ’wins’ and becomes the single point of contact for all synching (or maybe whomever is last, I forget how Tor handles conflicting but valid claims). In other words we form essentially a hub and spoke network with all devices updating the hub and the hub pushing (probably aggregated) updates to the spokes. This is actually a pretty natural model since it’s likely only a few devices will be plugging in all the time and the user is likely to only use one device at a time. What’s also nice is that Tor’s service reverses the connection so that the devices will always make outgoing connections over normal HTTPS and so have no issues with firewalls on most networks.

Another model is a fully mesh based model where every device in the mesh registers as a hidden service in TOR using its device key (which all the other devices in the mesh know the public key version of). Then whenever there is an update entered on one device it will push the update directly to the other devices by first finding their hidden services and sending the update. The benefit here is that things are more robust and there are no weird race conditions.

If a device isn’t online when an update goes out then either we can use a queue based mechanism to queue up the notification which could be retrieved either by pull or by repeated attempts to push.

There is a pathological case where, for example, a mesh consists of two devices who are never online at the same time. This is effectively a partitioned network. There is no magic solution to this. Depending on data size and latency requirements one could get around the partitioning problem by using a shared state network like Freenet to get other machines to carry the state and thus reduce the probability of partitioning. We need to see in practice how big a deal this is before we start introducing complications like external storage mechanisms. One could, of course, use a simple cloud storage service but this blows apart any kind of traffic analysis protection as the cloud storage service knows who you are and can see all connections. Although using something like Tor and sending messages on a regular basis with an encrypted payload of constant size could significantly reduce the quality of traffic analysis information available. But boy is that complicated.

There are more assumptions here about how updates work, a common storage service, etc. that we’ll get into later.

“We’ll have a long conversation about appropriate behavior in Social Networking but first lets talk mechanics. Here open up the PushFuzz app on your phone and ask it to create a publishing group, give it an appropriate name like ’Friends.’”

“But wait, I want everyone to see my update! Not just my friends.”

“Again, were going to have a long conversation about appropriate social network behavior. But o.k. lets say you want to make an update that everyone can see. Go back into PushFuzz and choose ’new micro blog message’. Now type in something appropriate like “Hello World”.”

“Hello World? Huh?”

“Don’t worry, it’s a geek thing.”

“So forget it. I want something cute. Like ’I’m a Belieber’”

“Clearly you are not old enough for a phone or a laptop, excuse me while I take your phone away and put the school lock back on your laptop.”

“Sorry... sorry... shesh... just kidding. How about ’Hi Everyone’.”

“O.k. fair enough. O.k. go get a free website from the usual suspects, something like wordpress.com or whatever. O.k. now go to PushFuzz on your laptop and go through the permission delegation steps to hook up your new wordpress site. Great and now click post update, for address, select everyone. Now type in ’Hi Everyone’ and click Post. There it is, you now have a world readable message.”

“But what if I just want to post something only my friends can see?”

“Keep in mind that you’re 10 and I will be in your posting list.”

“Dad!”

“10, repeat after me, 10. We’ll talk about this again in 6 or 7 or maybe 70 years. But that having been said go back to PeachFuzz and create a group. Right now you just have Brian so add him. Don’t worry PeachFuzz has a parent filter and I’m automatically added.”

Trudy looked at her father with less than filial love.

“I thought you were supposed to teach me to hate big brother.”

“Ahh... hypocrisy... yes... indeed. But here’s the thing my little girl. You are 10 years old. You aren’t even close to being an adult and you aren’t ready to take responsibility for your actions. One day you’ll be old enough that you can do what you want. But until then it’s my job to prepare you. Now that having been said it would be asinine of me to put more restrictions on your phone than in your real life. So here’s the deal. In your address book you can see which addresses are being monitored by me. Your friends from your local school won’t be monitored, and you can verify that, since anything you can say on the phone you could also say in person. I will also avoid monitoring key adults I trust. But otherwise any conversations you have with anyone not marked by me as safe will be visible to me. All group and other postings are also monitored and you can see in your address books which groups I’m monitoring. Over time as you convince me that you can handle the ability to talk to anyone, anywhere, without doing anything inappropriate then I’ll remove the monitoring. You can also go to the monitoring report to see a complete run down of what I’m being sent and any time you send a message that I can see a notice will be provided. It’s not great but, repeat after me - I’m 10. Handing something like a global communications device to a 10 year old is scary. But, as I said, as you demonstrate appropriate levels of maturity the training wheels will come off.”

“But... I mean... Dad... if you can monitor me can’t anyone else?”

“In theory no, in practice, yes. This isn’t a back door per se. This is a policy rule on your phone and is based on a master password that I control. So if someone can put a policy rule on your phone then they could also monitor you. But of course they could also just hack your phone.”

“But... I mean... my phone is like... you know... private. Am I always going to be watched?”

“I honestly don’t know. In theory the code on your phone is public and audited so hopefully there aren’t any unknown back doors. But zero day attacks are always possible. The bottom line is, you can’t trust your phone.”

“I can’t? Then what do you do to protect yourself Dad?”

“Well my phone is a bit special. First, it has an external battery so I can yank the battery and be reasonably sure it’s dead. Second, all the radios, cameras and motion sensors with the exception of WiFi are in a sealed unit that I can physically remove from the phone. The WiFi radio actually has a physical switch that physically disconnects it from the motherboard if I want but that’s less useful than it sounds. I also have a special chip on the phone that stores my keys and which handles all encryption and decryption on the phone so no keys are ever in normal memory or leave the chip. All requests for data, messages, etc. go through that chip. The chip is hardened so that if you try to interrogate it without the right password it won’t work and if you type in the wrong password four times it will dump state. It also has extra protections including a special brittle coating that if you try to drill through to contact the memory built in the chip directly the chip will fry itself. I also have a separate token that has to be in contact with the phone via wifi or the chip won’t take a password. But how useful all this is, in the real world, is questionable. I do it because I can.”

“So will my phone have all these features?”

“No, the key security feature your phone has is the removable battery. But that’s about it. When you get a bit older, and convince me that you won’t lose or destroy the phone, we’ll talk about more security.”

“But Dad, this all sounds scary.”

“It is.”

But what’s interesting is that once people do get the signature then Trudy could move to a different hoster and prove its still her using the signature. She can also notify all her friends of the change using the mechanisms below as well as a standard redirect assertion in her RSS/ATOM feed.

Private postings are a bit more complicated. If a group’s membership is visible to its members then when the group is created a notice will be sent to the group members letting them know about the group’s existence and also giving them a pub/sub address where they can register for notifications of membership changes in the group, postings to the group, etc. as well as a simple URL for the group where they can pull updates if they want.

So in our case when Brian finishes the identity exchange with Trudy via email as previously described as part of that exchange Brian’s machine would send a public key that can be used to get to Brian’s universal inbox. Brian’s devices would then register that key as a hidden service via Tor (or whatever) as previously described in device synching. So Trudy would use that address to notify Brian’s devices (which ever one currently grabbed the hidden service) of the group’s existence. Because this is an important update if Brian doesn’t have a device online (and isn’t using Freenet, GNUnet, a cloud service or whatever) then Trudy’s device will queue the message until it can be delivered.

Note that all of this would work just like any other REST service with the exception of finding and sending the messages to the hidden service. The most likely steps would be:

“Well let’s switch to your laptop, it’s screen is bigger. Open up SocialDemon.”

“Wait, how can I use PushFuzz on my phone and SocialDemon on my laptop? Aren’t the different programs?”

“Yes, but that’s o.k. They all use the same underlying store and that store is synched between your devices so everything works just fine.”

“Um... if you say so. What now?”

“So go to your address book in SocialDemon and click on the entries for people you want updates from.”

“Well, I want updates from everyone!”

“In that case just select all.”

“But what if I read something on my laptop, do I have to read it again on my phone?”

“No, as I said, both PushFuzz and SocialDemon are using the same underlying synch’d store so they share information on things like read entries.”

“I mean, o.k. but SocialDemon is o.k. for big stuff but lots of my friends send short updates. Can I use another program for that?”

“Yes. SocialDemon is a universal social app. All kinds of posts, photos, micro blogging, full blogging, position updates, personal messages, even normal email, etc. can be viewed as a single stream in it. But you can also use other apps that specialize in particular kinds of content. They all read off the same store and so share state. It’s fine.”

It’s also presumed that users would have a standard service on their devices where authorized requestors could ask ’what’s available to me about this user’? This would show groups the user is allowed to see, update streams, file locations, etc. all filtered based on what the requestor is authorized for. This would also provide discovery of things like pub/sub subscription locations or URLs to pull content. The discovery service would be accessed via a fixed URL off the universal inbox as previously described.

In general ’well behaved apps’ would keep their data using standard (but hopefully extensible) formats in the central store and would use that as a primary mechanism for sharing data. That way multiple apps can see updates, read markers, etc. I’m sure there are scenarios where data consistency rules won’t properly support sharing at a ’byte level’ in the data store and instead a protocol front end is needed. In that case the discovery mechanism would point to that service location. But there’s no magic here. It’s all just URLs that are communicated via hidden services or something similar. But the URLs would be onion URLs or some moral equivalent, not DNS based HTTP URLs. This does beg for introducing a new HTTP URL type that specifically is for hidden services, we really should just do that.

“Well, go to the sharing button and select address book.”

“Wait Dad, Mom is listed here twice once for ’Mom Personal’ and another time for ’Mom Work’. But you are only here once. I mean... you do have a job right?”

“Yes,” her father laughed. “I do have a job. But at my work they just put attestations on our existing identities but your Mom works for a hospital and they are paranoid with all the regulations. So she has her personal identity and a completely different identity for work.”

“But how does mom keep them straight?”

“Well actually it’s kind of cool”, at this Trudy actually groaned. “Oh stop that. What happens is that all of your apps are running in user mode VMs for security purposes and those VMs then run on a central VM which runs on the actual hardware. In your Mom’s case her phone actually has two different central VMs, one for her personal stuff and one for her work stuff. When she opens her phone she has to say which VM she wants to enter. Each root VM has its own different identity. So none of her personal data is mixed with her work data. Work can’t see her personal email or documents for example. This also means her work can remotely delete her work VM without interfering with her personal information. In my case my work just sends me an attestations that I work for them and it is attached to my identity.”

“O.k. Dad we’re back to ’huh’?”

“Sigh... look at my entry in the address book. Do you see where it says ’Validated: Works for randomcompany.example.com’?”

Trudy nods her head.

“O.k. so now look at Mom’s work entry. It says ’Validated: Works for hospital.example.com’. But look at her personal entry. It doesn’t say anything about her job.”

“Um... o.k. whatever. Who do I send the picture to?”

“You send it to Mom personal.”

“But Dad it’s asking me if the picture is to be shared or if its a gift. What does that mean?”

“This one is important so pay attention. When you share content with someone, either directly or via a group, most apps let you specify if the data is to be ’shared’ or ’gifted’. Shared means that you are asking the person to only look at the data, it could be a file or picture, for a limited period of time and then their device should delete it. When you share the data out the expected deletion period will be specified. If you say something is ’gifted’ then you are saying the person has the right to keep the information forever. As a general rule of thumb you should only share things, not gift them. If someone wants to see a particular picture or file again after it’s deleted they can always ask you.”

“But wait... isn’t that the... DRM or whatever stuff you are always ranting about?”

“No, it’s not. When you say something is a gift or shared that’s a request. There is nothing to enforce your request. Most well designed software will honor the request unless its told not to. But there is no mandatory enforcement mechanism. If someone wants to be a jerk and keep a copy of something you asked them not to there isn’t anything you can do. The point of this mechanism is to let people of good will honor each other’s requests. But if someone is acting badly or if they have a good reason to not follow the request, they can.”

“Good reason? Isn’t somebody a jerk if they keep something you said not to?”

“Not necessarily. Imagine someone is bullying someone and sending them threatening messages with a ’shared’ statement and a short delete date. They could use that to cover their tracks. So it’s important that people can override the request and keep something so they can show it to other people and get help against the bully. My problem with DRM is that it substitutes hardware for morals and I don’t want to live in that society. It’s my computer and if I do something wrong with it, fine, sue me or imprison me. But otherwise I need to be free to make my own choices and live with the consequences.”

“But wait, Dad. I just looked at my entry in my address book. It says ’Refuse Age Challenges’. What the heck is that?”

“It means your device will refuse to answer any challenges for your age.”

“Why does that matter?”

“Some sites will ask for an age challenge in order to keep under age users out. Your phone won’t accept those challenges.”

“So... what?”

“If the challenge isn’t responded to then the site won’t let you in.”

“Oh... my... GOD! That sucks!!!! Now there are tons of sites I can’t go to.”

“Repeat after me. 10. You’re 10. Be nice or I’ll put a white list on your phone.”

“This so completely sucks.”

Sharing vs gifting is just a tag that is included in data being sent to folks. It tries to capture the intent of the shared data. The idea is that if someone shares say a photo with someone else this isn’t intended to give the person possession of the photo for all eternity. So a default sharing policy might be for ’two views’ or ’three weeks’ or whatever. The idea is that the receiver, if behaving well, should honor that request. There is also a presumption that the information should be held in a way that isn’t easily recoverable once deleted. E.g. encrypted on a drive with a key that is kept somewhere that isn’t subject to retrieval once deleted (a problem with flash drives in particular although corrupt sectors in magnetic drives can have similar issues). But this is just a request. As Schneier would say, dissenters are critical for a dynamic society so DRM is off the table.

“Yes, Love?”

“Well I got this mail from one of my friends at school and it contains this game... and I played it and it’s fun. But right now it only lets me play with my friend. I want to play with other people too. It says I can install it but then it asks for all of these permissions. What am I supposed to do?”

“Lets see the permissions” her Dad responded. “O.k.,” Dad started, “it wants access to the network and to local storage as well as to your address book. That last one is a killer. If it needs to contact your friends it can do so through a permission dialog.”

“A what?” Trudy asked.

“A permission dialog, it will show you your address book in a way it can’t see, you pick which friends you want to tell it about and it just sees those. By asking for permission to your entire address book it circumvents that process but it also allows it to spam your friends. It’s extremely rare that you should ever need to share your address book. Remind me to reset your permissions to automatically reject any applications that ask for address book permissions.”

“But what about the game?” Trudy demanded.

“You can play it with your friend all you want but until the developer stops being a thief you can’t install it on your phone.”

“Dad!!!”

“Hey, don’t blame me. Pick games from honest companies who just want your money and not all your information.”

There are also situations where one device would want to do work on behalf of another device. For example I might want to edit pictures on my phone but have my phone actually outsource the work to my PC. In this case we just need a way to allow for one device to talk to another. This is already covered under synchronization but now the requests will go to a different endpoint. But everything else is the same in terms of mutual SSL auth to authenticate, onion/mixed networks/etc. What we really need is a standard way for apps to ask to listen on a port. All platforms have this for native apps and we need to extend HTML5 to add it for web apps.

But in many cases devices won’t want to do work for each other both because of latency as well as battery, storage and other issues. So, for example, if a user is using a mind mapper app and wants to edit the map with a friend who hasn’t installed the app then it should be possible for the friend’s device to download the entire app as a ’web app’ that runs in a sandbox with limited permissions. Hopefully the base case here would be HTML5, as I talked about here. The default permissions for one of these ’web apps’ would essentially be the permissions given to an untrusted site. Communication would only be allowed back to the device the app came from in the first place, limited storage, limited CPU, etc.. The user could, if they decide to trust the app, install it on their device as a trusted app. This doesn’t change the code, it just changes the permissions, quotas, etc. allocated to the app.

We should assume that all apps are sent in containers (e.g. ZIP) that we can generate hashes for and that the hashes are distributed separately from the app itself. The idea is that apps can be distributed peer to peer (rather than from a central, easily corruptible, endpoint) and that hashes would be checked in a similar peer to peer fashion. One would want to make a public request (using a hidden identity via TOR or equivalent) for the app’s ID and get responses for that ID. This is the kind of thing that a data escrow service would be good at. Services based on BitCoin make the most sense for this kind of data escrow. Essentially the publisher of the app would put the app’s ID and version into the BitCoin log along with the hash. This would publicize versions and hashes and allow for detection of attempts to create bad versions.

It also would be useful if the publisher of the app intentionally creates a bad version since typically such attacks are targeted and so the version ID would be rare. The more data that can be (securely) collected on how many people are running a particular version the easier it would be to detect any ’special’ releases. This protection is obviously not foolproof. It would stop people trying to masquerade as the entity that released the app but it wouldn’t stop the makers of the app from doing bad things, it would however provide some ability to detect ’special’ versions thus forcing the app maker to put their attack in all versions of the app and thus increase the probability of its being discovered.

The previous point is subtle (or more accurately, badly explained) so I’ll repeat it differently. Imagine that the open source project FooBar has a contributor whose computer was hacked by some advanced persistent threat (APT) style entity. That entity slips some ’bad code’ into the developers machine and the developer doesn’t detect the change and checks it into the FooBar source code base where it isn’t detected by security reviews and gets released. This kind of attack isn’t preferred by APT entities because everyone, everywhere will have the ’flawed’ product thus increasing the probability of the ’bad code’ being discovered. So what the APT entity would rather do is, for example, compromise the security of the server that hosts the FooBar project and when a specific targeted person does a download just give that person a bad version. But such an attempt would fail because the hash for the version put into the public escrow log (e.g. the BitCoin log) wouldn’t match the version downloaded. Keep in mind that all checking would be automatic. So now the entity would have to both give the target the version with bad code and give it a new version ID with a new hash that is in the BitCoin log. Now the window opens to at some point to detect something is fishy. Why is there is version that nobody but one person seems to have? Of course if the APT has enough money they could just attack BitCoin but that’s another story. The point isn’t a perfect defense, it’s just to increase the cost of an attack.

Note also that both the product name and version ID would be checked with the person who sent the app (who could be a bad actor of course) and we should expect attempts to validate the name and ID (as being real and meaningful) on the net. We would look for evidence that the app is widely used, public, etc. Again, there are tons of ways to game the system but that isn’t the point.

“Dad?”

“Yes dear?”

“My phone, well, it’s showing strange stuff. I don’t know. Ads or something.”

“Hum... let me see.”

Trudy’s Dad looks at the phone and determines that Trudy downloaded a program that had malware on it. The phone is now spitting up ads all over the place.

“Well o.k. this isn’t great. I told you to only download apps from the approved store.”

“I don’t remember downloading anything anyway.”

“Sigh... I actually do understand. Expecting end users to maintain security is suicidal. But your phone has been hacked. I’m not completely sure which app it is and anyway the app might have blue pilled your phone because you shouldn’t be seeing ads everywhere since the VM shouldn’t have allowed that. In any case all of your data, at least what the app could see, has been compromised. But that’s water under the bridge. Nothing you can do about that now. O.k. here’s what we are going to do. First, we have to assume your intermediate key on the phone has been compromised. So we have to revoke it. Also your laptop got its key from your phone so this is going to revoke your laptop’s key as well. We also can’t be completely sure of your laptop’s security since your phone could have passed malware to your laptop but we’ll assume that your anti-virus is working properly. This isn’t great but it’s the best we can do. Since we don’t know how long you were compromised since we don’t know which app caused this there is not much point in going back to a backup. I have your root key QR code in the file here. O.k. lets go to your laptop and tell it to use key revocation and reset. Lets put the QR Code in front of the camera. O.k. I’ll tell it to generate a new key and send out a revocation. It’s now telling everyone you know that they shouldn’t honor the old keys anymore and letting them know about the new key. After this I’ll flash your phone and we can put it back into your mesh via your laptop.

In this case the laptop would push an update to everyone in the address book/groups/etc. letting them know that all intermediate keys issued before a specified date are invalid. This isn’t perfect of course. Some people might not be reachable and people who haven’t dealt directly with Trudy could be fooled since they still have a legitimate intermediate key. Yes, we can put in a key revocation check mechanism but in practice they never seemed to work particularly well. Still it might be worth considering. The only real way to handle this ’well’ is to have roll over for intermediate keys but that is such a colossal pain that other than for high security scenarios I just can’t imagine it being worth it. Also note that any future identity exchanges or discoveries will include the revocation pretty much forever. So for example let’s say Trudy is in a group and someone who doesn’t normally talk to Trudy is also in that group eventually we would expect the revocation to get to that person transitively via the shared group since that is the kind of information that would be pushed out in an update. So her social network is going to learn about the revocation pretty quickly as will any affiliated social networks. Not perfect but probably good enough for most scenarios.

It’s tempting to argue that having the security crypto chip previously mentioned could prevent some of this pain but keep in mind that in order to add new devices to the mesh it must be possible for one device to create a chained cert for another device. That means that while the chip would keep the phone’s intermediate key from being compromised it can’t stop the compromised phone from having signed other compromised keys. So revocation is still needed to make sure all keys rooted to that intermediate key are killed.

“Yes dear?”

“Well.... my friends say that... well they say that they are getting some really nasty pictures from me.” Trudy looks apprehensive and then starts speaking really quickly. “But I didn’t send them. I swear I didn’t. I don’t know what’s going on!” At that point Trudy starts crying. Her father comforts here and says “Sigh... I was scared of that. My guess is that whatever compromised your phone also compromised your laptop. They can share data through the sync’d store and who knows what openings that provided. Unfortunately that all but certainly means your root key is now compromised since we used it on your laptop in its compromised state. Unfortunately that is really not good.”

Dad takes a deep breath and sighs before continuing.

“Obviously we are going to have to wipe your laptop and your phone.”

“But what about my pictures and friend lists and stuff?” Trudy nearly screams.

“Well we do have backups and I have a restore program that will just restore non-executable data. There are still some theoretical attacks, weird buffer overflows when parsing data, but I think we are safe enough with the restore program. But you will lose some data and more importantly your identity isn’t going to work anymore.”

“What? What does that mean?!?!” Trudy starts to sob.

“Oh sweetie, I’m sorry. But it means you are going to have trouble talking to people. We will send out a notice of root revocation. This will kill anyone trying to use your root key since such a revocation always takes precedence over anything else including a root roll over. But that just kills that identity. Now we have to replace it with a new one. This means completing tearing down your laptop and phone. It means trying to do a non-executable recovery from your backups. It means generating a new root key. Your will send out announcements to everyone in your groups with the new key but they’ll probably ignore it since they won’t recognize your new key and you will have removed your old one. You basically have to start over and convince people that your new identity is actually you and not someone trying to pretend to be you.”

By this point Trudy lost it and couldn’t stop herself from crying and sobbing uncontrollably.

“Oh sweetie... I’m so sorry. But it really isn’t your fault. We just don’t know how to properly secure these devices and expecting users to figure it out is insane. There is however a message I can send out to people who know us both letting them know your key. Their computers will identify me, who they know is your father and let them accept the new identity. That should pretty quickly take care of your family. But you’ll have to directly contact your friends.”

“But... but... what about websites and stuff?” Trudy managed to say between sobs.

“It depends. Some of them will let you change IDs via an e-mail challenge. But you’ll have to handle that on a case by case basis. For others... well... for high value sites like banks and such there are attestation servers but for normal websites... those are just gone.”

Trudy kept crying for quite some time.

We also need an attestation that can be sent out proactively where someone claims that an old key has been replaced by a new one. The root key revocation (signed by the root key, basically a suicide note) would be included in the announcement. Obviously this is still an identity thief’s dream since they can take the root key revocation announcement on its own and put it in their own new identity announcement. Fun times. But remember identity is always a shared construct. If you can convince enough people you are someone then that’s basically who you are and if you are a fraudster than pain will ensue.

Of course the even scarier scenario is imagine if Trudy had only one copy of her QR Code and she lost it. Now what? She can’t even send out a signed revocation! In that case her Dad could still send out an attestation of a new identity but boy is that not going to be fun for anyone to deal with. It just comes down to who people believe.

In the case of banks and other institutions they are likely to have their own recovery procedures. Either they will verify (and I use that term while laughing if you have seen how most banks do identity verification) the user’s identity themselves and then replace the old key with a new one in their records or they might (I doubt it, but it’s a fun thought) use a formal attestation service. This has been a dream in the identity world forever. The idea is that there is some central authority (could be a government, the EU has been investigating this forever and I believe has some pilots) who hands out identity attestations. So if your root key was compromised you could go to the central authority, get a new attestation (and a revocation of the old one, useful if you lost your root key) and get right back into your accounts. At least for those who honor the central authority. Of course the range for abuse of a system like this are somewhere near infinity.

Depending on how hard it is for normal humans to manage their root keys I wouldn’t be surprised if we don’t see a lot of what are sometimes called ’managed identities’. Certainly corporations are likely to use them (until they give up and switch to attestations which I expect they’ll probably do because they’ll get sick of being in the identity management business) but I wouldn’t be surprised if consumers will use them to. The downside is that the identity provider can become you at will (in response to hacks, government orders, etc.) but if your devices are compromised you have one stop shopping to get your identity back. For many people that might be a tradeoff worth making.

There is another approach that could have made this situation less awful but I thought it was too complicated for use in practice and it isn’t perfect. There could have been two different keys printed out when Trudy created her identity. Assuming Trudy had a freshly formatted computer and that the OS/apps/etc. on the new machine weren’t compromised then Trudy could have had two keys. One is the true root key used to create new intermediate keys. The other key would be a roll over key. All it can do is roll overs. In theory then Trudy’s dad could have gone to a ’trusted’ machine (try not to laugh) once he knew all her devices were compromised and created a new identity and signed it with the roll over key. Since the roll over key is only used during a roll over it wouldn’t have been compromised when Trudy’s laptop compromised her root key (needed to create the revocation). Now one could make a few arguments here. First, why did the laptop need the root key to revoke the phone’s intermediate key? In theory the answer is that the laptop’s key was a child of the phone’s key and so in theory shouldn’t be able to revoke its parent. But we could have set up a situation where any key can revoke any other key. But that just makes an attackers job easier by locking out unhacked machines (by revoking them) so it’s the only authorized machine left. So in practice we really needed to use the root key to do the revocation. Second, why the heck didn’t Trudy’s dad flatten the laptop before using the root key? He probably should have but restoring is such a nightmare, especially if you are worried about the backup being compromised. And in any case there is always a bottom turtle. For all Trudy’s dad could know the image he used to flatten the laptop could have been compromised and we would be right back to this scenario. So my guess is that keeping things as described in the scenarios (e.g. a single root key used both to revoke intermediate keys and itself) is the least awful pattern.

Last Used ID: AAM