A Bluffers Guide To IBE - jim-b/ECCSI-SAKKE GitHub Wiki

light hearted overview for polite conversation at dinner parties

IBE just means Identity Based Encryption. Mikey-Sakke is one such IBE mechanism. Yeah, but what does that mean? Well, we all have loads of identifying information, telephone numbers, email addresses, health number, login credentials to various things, NI (National Insurance)/ SSN (Social Security) etc etc. So, let's just look at telephone numbers (which is really the intended first use of Mikey-Sakke) and discount the others for some future time/ research project.

Wouldn't it be cool if you could stop others looking at your communications i.e. encrypt your telephone calls and/ or texts (and in future your emails etc etc), and, all you needed to do that, was use one of these identities (for example, telephone number) and that of the person you're calling/ texting?

Well, you can't! It's a bit more complicated than that, but not much... there are a few other considerations:

  1. Firstly, the algorithm (series of steps) used by both parties for the encryption needs some other Key Material to make it secure, otherwise anyone could listen in/ read the texts, just by applying the same mechanism to encrypt/ decrypt (i.e. just pretend to be one of the people in the call).
  2. If you need this extra Key Material something has to be in control of it, manage it and distribute it. Now, if this something is owned or operated by one national or global organization, you (and others who you may communicate with) have to ask yourselves, "Do I trust this organization for all my (possibly sensitive) communications? If they have this key material, together with my Identity and the algorithm, they may listen in or see my texts or emails?".

So, this introduces the concept of communities, each community has it's own extra Key Material that it manages and distributes (via something called a KMS - Key Management System). This extra Key Material is different (Private) for each community. People registered with one community are assumed to have an existing (trust) relationship with it and other members of the community i.e. employees of a company or subscribers to a particular service. 3. Next, you need some way provide a lifetime to (or mechanism to revoke/ retire) Key Material used by a user within a community; Devices get lost, people change jobs, people stop using services, devices get (or suspected of being) compromised etc etc.

To achieve this Mikey-Sakke includes a date element in the identity (month/ year) after which new Key Material must be acquired.

So, with these considerations in mind, what do we have:

User Identifiers now have additional date and community elements:

Identity == Date + Identifier + Community
  where Identifier may be Telephone-Number

and, a KMS securely provides Key Material for these date/user/community identifiers. A user can exist in more that one community, but the identifier that will be used will change (because the community has changed).

Now, with the caveat that you trust the operator of the KMS, the Mikey Sakke RFCs 6507, 6508 and 6509 describe mechanisms by which users (within a specific community) can:

  1. Sign messages, indicating they are the (genuine) originator of the message.
  2. Verify that a user was the signatory of a message.
  3. Encrypt a message for another (specified) user within the community.
  4. Decrypt a message from another user within the community (if it was encrypted for the decrypting user).

The really cool aspect is that users (within a community) can do these things without ever having a previous interaction (for, say Key Exchange) with the other party, as long as both are in the same community. For example, you can have an encrypted call with someone (within the same community) who you may have never spoken to (or exchanged keys with) before.