Introduction of the cryptosystem
Let’s say we have a system with a central server
SRV that is considered secure (communication with this server is secured too with TLS).
Then let’s say we have many clients
CLIENT which are supposed to be secure too (their firmware is encrypted with a per-client unique, non readable key)
Finally, we have some tag
TAG that can store some data unencrypted and only one secret item with a key of our choice. The
TAG contains a unique identifier but this can be spoofed.
The communication between
TAG is unsecure (can be eavesdropped). Yet, the
TAG contains a authentication scheme that can be used to certify
CLIENT knows the same secret key that’s stored in the
TAG and prevent reading the secret item if the authentication failed.
Authentication does not reveal the secret key.
So for a simple diagram, it looks like this:
SRV // \ CLIENT1 CLIENT2 --- TAG1 \__ TAG2 // double line means secure communication, simple line means insecure communication
I want to perform the following features:
TAG could be enrolled on any
CLIENT learn the
TAG and store some identifying information in its own memory and also on the
SRV. It can store information in the
CLIENT should recognize an already enrolled
TAG securely without connecting to the
CLIENT should recognize a
TAG that its has not enrolled by connecting to the
CLIENT should allow to forget an enrolled
TAG (with or without connection the
SRV) and when this happens, such
TAG should not be accepted anymore on another
Please notice that I can’t use the
TAG‘s unique identifier because it’s not unique (one can spoof such identifier either by reading the
TAG or by emulating a
TAG), so storing the
TAG UID in the
SRV is not safe.
Also, using a common shared secret between
SRV to store on the
TAG secret’s area is not safe either since any tag emulator will capture such secret when it’s programmed on the
TAG‘s secret key (this is done in clear).
I’m thinking of using Shamir’s secret sharing
SSS here with the number of share set to 2 and the number of part set to 3.
Typically, the enrolling process is:
- Read the
TAG UID as
- Read some data in the unsecure area as
KeyTag is not empty, exit enrolling
- Pick a random
Key to make 3 parts:
CLIENT memory for the
KeyTag in the unsecure area of the
- Send (
TagUID => KeySrv) to
SRV for remote storage
Key to the
Tag secure vault (so next authentications will require such key)
- Store some ID/signature/HMAC/Whatever in the
TAG‘s secret area
TAG recognition process is like this:
- Read the
TagUID from the
KeyTag from the
TAG unsecure area
If there is a
KeyClient for such
KeySrv for such
TagUID 3.2 Compute
- Authenticate with
- Read ID/signature/HMAC from the secure area, and check it’s valid.
TAG forget process is:
- If connected, remove such
KeyTag from the
- Authenticate with the
TAG (following the previous process)
- Erase secure area from the
- Erase authentication from the
KeyClient for this
This scheme seems secure from the many scenario I’ve thought about, yet I need some expert checking here for what I might have overlooked.
Here are the cases I’ve thought about:
- When used with a tag emulator, one could intercept the random
Key for a given
TAG but that should not compromise the security of the other tags or other clients. That is, such emulator when used on other
CLIENT will be detected as a valid
TAG, yet it can’t read any other
TAG nor inpersonate them.
- If the
CLIENT is disconnected from the
SRV while forgetting a
TAG, it’ll still wipe the
TAG thus there will be no more a
KeyTag on it and as such it can’t be decoded anymore. Here the
SRV could contain stale
TagUID, KeySrv combination, but that should not hurt.
- An emulator providing wrong
KeyTag does not gain anything since computed
Key will not pass authentication and it’s not possible to read a
Key once programmed. Thus, the ID/signature/HMAC reading will not pass.
- A attacker opening a
CLIENT would not get any information since there is no common secure key in the
CLIENT for all tags. At best, she could get the vault of
KeyClient for each
TAG but in order to gain advantage, it would also need the
KeyTag for each
- Any eavesdropping on the
SRV communication should not reveal anything, since it’s protected by TLS.
Did I miss anything ?