Authentication protocols for authenticating devices to a server

Question

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?

Answer 1

"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}$.