0
$\begingroup$

i am trying to figure out a man-in-the-middle safe authentication scheme for some devices. I understand that this could be achieved via CA's.

But what is unclear to me is how can the authenticity of a device be guaranteed in such a setup. To me it seems that a DEV3 (an imposter) could easily send its public key to the CA, which is then signed by the CA. Also, DEV3 probably has CA PUB key.

Here is a doodle :

enter image description here

$\endgroup$
  • $\begingroup$ Is question 3) assuming step 2) has already occurred, in which case it should be "How does CA know that Dev3 was not imposing as Dev1 at step 2)"? Otherwise, what's wrong with the answer: by keeping Dev1's public key at step 2), and using at step 3) a protocol with messages putatively from Dev1 incorporating a fresh challenge from CA and signed using Dev1's private key, such that the CA can verify the signature against Dev1's public key? $\endgroup$ – fgrieu Feb 16 '16 at 16:12
  • $\begingroup$ Yes, my concern is that in step 2 the key that is being signed by CA originated from DEV3 instead of DEV1. I updated the doodle. $\endgroup$ – ele lont Feb 16 '16 at 16:20
2
$\begingroup$

The problem asked is not easily solved. To authenticate using cryptography as Dev1 in a way that a rogue Dev3 does not allow to imitate, Dev1 must know some secret key (or private key) that Dev3 does now contain (or does not allows to either extract or misuse), but that the CA can verify because it knows it (or knows the corresponding public key). Conventional cryptography (including public key cryptography, but perhaps not PUF-based cryptography or/and novel uses of quantum cryptography, which I won't consider further) has nothing else to offer.

The easiest workaround is to consider that Dev1 is whatever can prove being able to use the private key associated to the first public key for which the CA computes a certificate for something allegedly named Dev1, and have the CA reject any further attempt at obtaining a certificate under the name Dev1 (possibly: with the exception of duly authenticated certificate renewal requests if these are in the picture). When done properly, that can prevent Dev1 from working at all when it can be impersonated, which is better than nothing.

One method of solving the problem rather than working around it is to perform step 2 in an assumed secure location (e.g. factory) where the authentication of Dev1 is performed by non-cryptographic means.

Another method is to inject a secret key in Dev1 at a secure location, known also to the CA, so that step 2 can be performed with authentication using secret-key cryptography. That secret key can be a random octet string assigned at the secure location, and securely communicated (associated to the identifier Dev1, or the public Media Access Control address (MAC) of Dev1 if it has no name at that stage) to the CA, or the other way around.

As a more convenient variant of the above, the secret key can be a so-called diversified key, obtained using a key derivation function from a master key (known to the entity operating the secure location and the CA) and whatever identifies Dev1; the benefit is that only the master key needs to be securely communicated from/to the CA, which can recompute the diversified key of all devices. Note: for key diversification we do not need an entropy-streching key derivation function, and can use e.g. HMAC or AES (with the master key as key, and the identification as the other input); or any of the functions in NIST SP 800-108.
The key can be a Message Authentication Code of the Media Access Control address. The collision in TLA is accidental.

There are other methods, like embedding the same secret in all devices, and hoping it will not be extracted or misused; but they tend to have no operational advantage compared to the previous one when there is a CA, and be more brittle.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thanks for the reply. I can still imagine some scenarios that would be potentially dangerous: "Easiest workaround": DEV3 will be capable of proving that he can use the private key, since it sent the matching public key to CA and has a matchin private key. | MAC based solution: What if an attacker (DEV3) reads out the MAC from DEV1 (physical access) and sends it during the pairing process? This way the DEV1's MAC (that is preset in CA) is unused and CA will sign the key. $\endgroup$ – ele lont Feb 17 '16 at 19:19
  • $\begingroup$ @ele lont. You are right. In easiest workaround, we only prevent the true Dev1 to work if impersonated. In "Another method" or its variant, an adversary that reads Dev1's secret key wins. Notice that in any conventional crypto solution, an adversary that reads Dev1's private key wins, so the problem in the secret key solutions is of the same nature and thus remains tolerable; we can see Dev1's secret key as a temporary private key, restricted to the initial relation with the CA. $\endgroup$ – fgrieu Feb 18 '16 at 6:26
2
$\begingroup$

You cannot establish trust out of nothing. You need some kind of out-of-band method to establish initial trust. How this is performed depends on the devices. E.g. Bluetooth devices are paired by pressing the button, displaying the device type on the screen of the master device, and then accepting that connection. But in principle anything could do, as long as the trust can be established.

One way would be for somebody to bring the devices together, if that's not something that an attacker can do. In that case the device can receive the public key over a contact interface. As the contact interface is trusted the public key cannot come from device 3. Once the certificate is received by device 1 or 2 the device that contains the network can rely on the trust established beforehand.

| improve this answer | |
$\endgroup$
  • $\begingroup$ But there is still the possibility that someone with a huge antennae intercepts my device and sends me a fake key when the key press based pairing is in progress. $\endgroup$ – ele lont Feb 17 '16 at 19:08
  • $\begingroup$ Yes, that's true. In the end it's about risk assessment. Sometimes simple methods of authentication work pretty well. $\endgroup$ – Maarten Bodewes Feb 17 '16 at 21:43
0
$\begingroup$

To answer the specific part of the query: To me it seems that a DEV3 (an imposter) could easily send its public key to the CA, which is then signed by the CA.

=> What you mentioned is not impossible, but to mitigate the risk of being fraud by imposter usual CA Signing authorise are tough about there validation process (CA Authorities checks all documents), specially if thats related to financial transection. However technically if some defaulter able to impose itself as DEV1, and got the DEV3 certificate, than yes SSL is no longer secure.

| improve this answer | |
$\endgroup$

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.