0

I'm trying to understand a series of steps for an authentication system I want to replicate. The steps are executed by this script. To sum up, it does the following:

It runs in a Raspberry Pi and the main objective is to register and login the device in a server.

  1. First, runs openssl in the RPI to generate a private key.
  2. Then, it requests the server a token for the new device.
  3. With the token and the private key, generates a certificate signing request, again with openssl.
  4. Finally, submits a "CSR with activation request" to the server API that receives a certificate in case of success.

I understand all steps except number 4.

  1. What does the server do in this step to validate the request?
  2. And how it generates the certificate (is this the self-signed certificate?)?
  3. Finally, how will this be used in the future for the authentication process (asking here for the general idea, not the code)?
0

What does the server do in this step to validate the request?

The request includes a device specific token which has to be obtained for the registration can be finished. From the script:

if [ -z "$TOKEN" ]; then
    echo "Visit the Alohacam dashboard to obtain an activation token for this device:"
    echo "    $DASHBOARD_URL/devices/"

And how it generates the certificate (is this the self-signed certificate?)?

This is unknown. I cannot find any information in the documentation there is no source. From the README:

We're not planning a public release of our code base ...

But actually, it does not really matter. All what matters is that the certificate will be trusted by whoever accesses the device. I'm pretty sure that the certificate will not be issued by a publicly trusted CA (since no public domain names are involved). So it will either be a self-signed certificate or a certificate issued by a private CA. In both cases normal clients (like browsers) will initially not trust the certificate.

Finally, how will this be used in the future for the authentication process (asking here for the general idea, not the code)?

Again, there is no code. But based on the statement from the README a TLS connection will be initiated to the device and the generated certificate will be used to authenticate the device, i.e. the usual way of how TLS works:

We use client side SSL/TLS encryption. The Alohacam install script will auto-generate a certificate for your device. This certificate never leaves your device – we don't store it or have access to it – and you can even use your own. When a connection to your device is initiated, your browser will create a dynamic certificate (through DHE key exchange) that is valid only for that session. Both certificates use X.509 standards. We designed these security measures to ensure that only you will be able to view your Alohacam!

Actually, the last part about the browser creating a dynamic certificate through DHE key exchange does not make sense for me. I'm not sure if this is just badly worded, that they did not know what they were talking about or if I'm too stupid to understand it.

3
  • Ok, thanks. I thought that they were following a standard protocol. I'm no expert al all in ssl and so I'm still a bit lost (In fact I don't know what really is a self-signed certificate). You say "a TLS connection will be initiated to the device and the generated certificate will be used to authenticate the device". How does that work? Does this certificate must be always created from the server side? – Miguel Oct 31 '20 at 15:59
  • 1
    @Miguel: First, "client" and "server" here have different meanings depending on the context. For the certificate generation the client is the script and the server is the one issuing the certificate. For access the client is the browser and the server is the raspi. The certificate will be installed at the raspi, so that it can authenticate itself as server when accessed by HTTPS. How TLS, HTTP and certificate validation work is really out of the context of this question and there are many places where a description can be found. And the process of generating the certificate here is not common. – Steffen Ullrich Oct 31 '20 at 16:50
  • Ok, thanks for the explanation. – Miguel Oct 31 '20 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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