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:
TAGcould be enrolled on any
TAGand store some identifying information in its own memory and also on the
SRV. It can store information in the
CLIENTshould recognize an already enrolled
TAGsecurely without connecting to the
CLIENTshould recognize a
TAGthat its has not enrolled by connecting to the
CLIENTshould allow to forget an enrolled
TAG(with or without connection the
SRV) and when this happens, such
TAGshould 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
- Read some data in the unsecure area as
KeyTagis not empty, exit enrolling
- Pick a random
Keyto make 3 parts:
CLIENTmemory for the
KeyTagin the unsecure area of the
- Send (
TagUID => KeySrv) to
SRVfor remote storage
Tagsecure 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
If there is a
- Authenticate with
- Read ID/signature/HMAC from the secure area, and check it's valid.
TAG forget process is:
- If connected, remove such
- Authenticate with the
TAG(following the previous process)
- Erase secure area from the
- Erase authentication from the
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
Keyfor a given
TAGbut that should not compromise the security of the other tags or other clients. That is, such emulator when used on other
CLIENTwill be detected as a valid
TAG, yet it can't read any other
TAGnor inpersonate them.
- If the
CLIENTis disconnected from the
SRVwhile forgetting a
TAG, it'll still wipe the
TAGthus there will be no more a
KeyTagon it and as such it can't be decoded anymore. Here the
SRVcould contain stale
TagUID, KeySrvcombination, but that should not hurt.
- An emulator providing wrong
KeyTagdoes not gain anything since computed
Keywill not pass authentication and it's not possible to read a
Keyonce programmed. Thus, the ID/signature/HMAC reading will not pass.
- A attacker opening a
CLIENTwould not get any information since there is no common secure key in the
CLIENTfor all tags. At best, she could get the vault of
TAGbut in order to gain advantage, it would also need the
- Any eavesdropping on the
SRVcommunication should not reveal anything, since it's protected by TLS.
Did I miss anything ?