Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The requirement is to authenticate 1000s of devices to a server when the devices try to contact the server. The problem I face is that all authentication protocols require some kind of shared secret between the devices and the server. And for devices to know this shared secret, some reliable user has to manually enter the shared secret into the device. This manual step is undesirable. The goal is to have the devices start contacting and authenticate with the server with as little manual intervention as possible.

To elaborate a bit, two options I could think of are:

  1. Inject a shared secret that only the server can the generate and verify(eg: a digital signature of a random string by the server) into the devices. The server and device use some standard authentication protocol using this shared secret. But for bootstrapping this setup, a shared secret needs to be injected for each device manually by an user. I am wondering if there is a way to avoid this step.

  2. The device and server agree on some obscure algorithm. The device would apply this obscure algorithm on some common entity that both the device and server know (like the Serial Number) and send to the server. The server will also apply the same algorithm and verify that it could generate the same secret. Here the shared secret is the algorithm. Although this option doesn't require someone to manually enter a shared secret, this option doesn't sound secure or convincing to me.

In general, are there standard protocols that solve this problem?

share|improve this question
Why don't you start by describing what you want "authenticate" to mean. Ultimately, after the server has "authenticated" the client, what do you want to be guaranteed? How will you use the information that the client is "authenticated"? In what way will you treat the client differently, and why? There are so many possible goals for authentication: to verify that you're talking to a client that's administered by someone in the same organization, that you're talking to a client that was authorized by one of your legitimate users, that you know the serial number of the device you're talking to... – D.W. Aug 29 '13 at 7:26

"The problem I face is that all authentication protocols require
some kind of shared secret between the devices and the server."

Similarly, the problem I face is that $\:1 = 0 \;\;$.

Since your post includes "(eg: a digital signature of a random string by the server)", I will assume
that the server has a signature key-pair and the devices alrady know that pair's verification key.
To start, the device generates a signature key-pair $\:\langle vk_{\hspace{.02 in}d}\hspace{.02 in},sk_{\hspace{.02 in}d}\rangle\:$, $\;$ and sends $vk_{\hspace{.02 in}d}$ to the server.
When it receives a value $vk_{\hspace{.02 in}d}$, the server generates a random value $\:\operatorname{token}\:$, $\:$ sends that along with
a signature on the pair $\:\langle vk_{\hspace{.02 in}d}\hspace{.03 in},\operatorname{token}\rangle\:$ to the device, and stores $\:\langle \text{current_time}\hspace{.02 in},\hspace{-0.02 in}\text{token}\hspace{.02 in},\hspace{-0.02 in}vk_{\hspace{.02 in}d}\rangle\:\:$.
The device tests the signature. $\:$ If the signature verification algorithm accepts, then
the device displays $\:\operatorname{token}\:$ and the user manually authenticates that value to the server.
When a value is manually authenticated to the server, it deletes all triples whose left entry is too old, where "too old" depends on how many triples there are, and for each remaining
triple whose middle entry was just manually authenticated, the server stores $\langle vk_{\hspace{.02 in}d}\hspace{.02 in},\hspace{-0.02 in}\text{context_from_the_manual_authentication}\rangle\:$ and then
deletes that triple and accepts the device as authenticated.
The server also deletes the oldest triple(s) whenever the list of
triples gets too long or the left entry in those triples is way too old.
Subsequently, messages from the device to the server can be signed with $sk_{\hspace{.02 in}d}$ and verified with $\hspace{.01 in}vk_{\hspace{.02 in}d}\hspace{.02 in}$.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.