I thought a bit more about the details of encrypting the account database. This is a first attempt at defining the general structure of the cryptosystem:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/crypto-accreg-20150418.pdf Some optional features are drawn in grey. I'll discuss them towards the end of this mail. The whole drawing is a little complex, sorry about that. For a more gentle introduction, I'll have to break it down into smaller pieces. What this shows is the process of encrypting and decrypting a record of the account database. The record would contain the password and may contain other things, e.g., the name of the account record (e.g., "My server"), maybe some URL or address, a user or login name, etc. This information is encrypted such that all the authorized readers (i.e., Anelok devices and any other trusted systems) can read it. For simplicity, I assume for now that we have a trusted source for the public keys of the authorized readers (and only of readers who are authorized). This source is shown as the "Authorized" box. Writing ------- When creating a new account record or when editing an existing record, the writer first prepares the record's content ("Plaintext"), adds a checksum ("MIC", Message Integrity Code), then generates a key ("Record key") and uses this key to encrypt plaintext and checksum with the symmetric cipher "Esym." The writer then has to attach the record key to the record in a way that lets the readers retrieve it. It does this by performing Diffie-Hellman key agreement (ECDH [1]) using its own private key and each reader's public key. ECDH provides us with a shared secret for writer and reader. We then mix the bits in this secret with a key derivation function ("KDF" [2]), use it to encrypt the record key for the respective reader, and add this encrypted key to the record ("Alice EK", etc.) To allow the reader to find its encrypted key, we use the reader's public key as identifier and add it as well ("Alice PK"). This is done for every authorized reader. The encryption algorithm ("Esym" again) may or may not be identical to the one we used for the actual content of the record. Last but not least, we also store the public key of the writer in the record, because the readers will need (*) it to compute their shared secret. The little "P2P" boxes translate a private key to the corresponding public key. (*) We'll revisit this in the following mail. Reading ------- To decrypt an account record, the reader performs the ECDH key agreement using its own private key and the writer's public key. Then, after applying the KDF, we decrypt the encrypted record key with it, using the decryption function of the symmetric cipher ("Dsym"). The reader selects which encrypted key (e.g., "Alice EK") to use by searching for an entry with its public key in the list of public key and encrypted key pairs. Once we have the record key, we can decrypt the record (the second "Dsym") and verify the checksum. Checking the integrity can be important if an incorrect password could produce a denial of service situation worse than merely not being able to retrieve the password, e.g., when an ATM eats the credit card after three failed attempts. So far, this is all nice and easy. Now, can we make it more interesting ? Yes, of course we can ! Authentication -------------- I already mentioned denial of service. Now, it would be easy for some malevolent person with access to our encrypted record to just create a fake record with incorrect information, encrypt it with their own public key (we assume that the public keys of readers are generally known), and then add their own key as the writer's public key to the record. If we assume that we also have access to a trusted list of writers (which may just be the same as our list of authorized readers), we can whether a record's writer really is authorized simply by looking up ("Find") the public key in the list. If it's not there, the record is bogus. And if it's there, and someone else has written the record, it should fail the integrity check. I'm not sure yet whether something as simple as, say, a CRC would be sufficient for this, or whether we need a cryptographic hash function [3] to make sure the integrity check is not easily fooled. Next mail: anonymity, or something like that. - Werner [1] http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman [2] http://en.wikipedia.org/wiki/Key_derivation_function [3] http://en.wikipedia.org/wiki/Cryptographic_hash_function _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
