1

I have been reading a lot about encryption lately but most sources just care about making sure that the connection between two parties is secure. I want to know how I can be sure that the party I am talking to is actually the party I want to be talking to.

As far as I can see I can use something like AES-CCM to encrypt my messages and the keys used for this encryption can be shared using public-key algorithms. But what step do I need to take before that? Because is it not possible for another party to just simply initiate the public-key sharing with my device, which is then in turn used to share the symmetric key for AES-CCM?

I thought that the party that is trying to communicate with my device first needs to proof that he is authenticated to do so through some sort of password maybe. But that does mean I somehow have to save the password securely on my device. Is this how it is normally done? And if so how do I save this password securely?

I found this PDF file about a crypto-bootloader from Texas Instruments: http://www.ti.com/lit/wp/slay041/slay041.pdf. Here they simply save the keys in MPU-IPE which protect it from read/write access. But my device does not have that option.

Any insight into this topic would be highly appreciated. I am developing on Texas Instruments CC2652R1 in case anyone has experience with implementing this sort of thing on this device.

Vincent Kenbeek
  • 193
  • 9
  • 5
    I’m voting to close this question because it's not a valid EE question for this site. – Andy aka May 01 '20 at 12:25
  • 3
    @Andyaka, where else should I post this? I though EE was also used for Embedded Systems? – Vincent Kenbeek May 01 '20 at 12:28
  • 1
    I think you are talking about certificates. See this video https://www.youtube.com/watch?v=PO8YQYF4D20 even though it is about PICs. There is a security.stackexchange.com which is better suited to this sort of question. – Martin May 01 '20 at 12:29
  • @VincentKenbeek I have no idea where. – Andy aka May 01 '20 at 12:30
  • 1
    There is a crypto stackexchange. I don't think it's entirely off topic here. – pjc50 May 01 '20 at 12:48
  • Thank you. I thought it was more appropriate for this stackexchange because of the securely saving data on an embedded device aspect of my question. But if I don't get much information here I will move my question to the crypto or security stackexchange. – Vincent Kenbeek May 01 '20 at 12:53

2 Answers2

2

Two-way authentication requires two pairs of keys.

Your device has a private key, and any other device that has the corresponding public key can send it encrypted messages.

If you want to only accept messages from one (or more) specific device(s), then your device needs to also have a copy of the public key that corresponds to that device's private key. This allows you to verify that the incoming messages were in fact signed by that other device and no one else.

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393
  • And what would be the best way to store these keys on the device? Because storing it in flash memory is not very secure, right? – Vincent Kenbeek May 01 '20 at 12:49
  • Don't store keys, negotiate them when the connection is made. Look up the Diffie-Helman key exchange algorithms. – Ron Beyer May 01 '20 at 13:04
  • @RonBeyer But isn't Diffie-Helman non-authenticated? My problem is not making sure that data is encrypted but that the connection was made with the correct party. So if I use the Alice and Bob example, how can I as Alice make sure I am communicating with Bob and not someone else pretending to be Bob? Doesn't this require some sort of key? – Vincent Kenbeek May 01 '20 at 13:09
  • Once the connection is secure you can authenticate however you like, just don't exchange keys over unencrypted connections, even (especially) if that connection is with a bad actor. – Ron Beyer May 01 '20 at 13:17
  • @RonBeyer But the whole authentication part is what I am asking about. How am I going to do that securely? Because doesn't all authentication rely on some form of password/key? How can I safely store this key on my device? – Vincent Kenbeek May 01 '20 at 13:45
  • Password/key or challenge/response are big ones. You could also use an external service. It really isn't a lot different than doing it on a computer, except on a computer a lot of the details are abstracted away. – Ron Beyer May 01 '20 at 13:52
  • @VincentKenbeek -- there is something called "authenticated Diffie Hellman" which is more complicated than "standard" D-H, but nowadays the only use of D-H in the real world is authenticated. You can also use pre-shared key (PSK) but that is a mess. – Radian May 01 '20 at 19:15
1

OK, I actually teach this stuff.

the quick answer is to use SSL-TLS, it has everything you need baked in. I believe your chips supports SSL/TLS already in ROM, see this IoT app note.

With Transport Layer Security (TLS), you use public key cryptography to establish an ephemeral / transient set of keys for symmetric encryption and authentication (MAC). The server sends the client (client = initiating party) its certificate, which carries its (the server's) public key.

So why should the client trust the certificate, i.e., that's it's really from the server, and not an attacker ("man in the middle")? Well, at first it shouldn't. The client should check the certificate's /signature/. I won't get into this, but if they client validates the signature, it should trust that the certificate and the public key on it are authentic. The client uses a certificate loaded into its trusted root store (or "root of trust", or "root certificate store", or any other of 100 names that are used) to authenticate the signature on the server's certificate. I think on the TI CC chips it's called the Trusted Root-Certificate Catalog. This is often referred to as a "chain of trust" in the security world.

Once the client "knows" (hopes, with strong confidence) that it has the server's public key, the 2 parties can exchange information to establish session keys and thus a secure channel (encrypted and authenticated). How all this works isn't technically too complicated but there are many steps and checks that I can't document here. But read up on TLS, and it should all make sense.

The latest version of TLS is 1.3 (summer 2018), this is the "latest and greatest" and what you should be using. Of course, the other side (client or server) needs to support 1.3 as well, but unless it's an old legacy device that is not being updated, it should support v1.3 by now.

Hope that helps.

Radian
  • 819
  • 8
  • 11
  • This addresses *encryption*, not *authentication* that the OP is asking about. The OP wants to know that once a connection is established, how do they know that the other end is *authorized* to talk to the device. – Ron Beyer May 01 '20 at 18:54
  • @RonBeyer - Sorry but you're incorrect. It's both, heavy on authentication. Public key cryptography is used to authenticate the parties so that they can establish an encrypted, authenticated channel. Once the secure channel is established, every packet is cryptographically authenticated with a MAC. Do you not understand TLS? – Radian May 01 '20 at 19:00
  • Yes, I understand TLS, which usually requires that the server (the device in this context) provide a certificate to the client which the client verifies (typically via a third-party certificate store). The OP is asking the other way around, where the device authenticates the client. TLS can do two-way authentication obviously, but the OP is wondering how to do the certificate store side (if using TLS) on a device that may not have access to a third-party verification store. – Ron Beyer May 01 '20 at 19:05
  • @RonBeyer -- OK thanks for the reply. I think I cited the chip's app note, it has built-in TLS/SSL (I've worked with TI on this chip) and also it supports a secure key/certificate storage in its security processor. I did a disservice by not explicitly mentioning 2-way authentication in TLS because it's not as common, but you are correct that this is one of those use cases. – Radian May 01 '20 at 19:12
  • This looks very interesting, thank you. I looked into the documentation for the CC2652R but I did not see SSL or TLS mentioned anywhere (http://www.ti.com/lit/ug/swcu185d/swcu185d.pdf) and googling for Trusted Root-Certificate Catalog only shows results for the CC3220. As far as I can tell there is no secure storage of any kind available on my device. – Vincent Kenbeek May 03 '20 at 08:13
  • @VincentKenbeek -- you are correct, my apologies. My last work was with the [CC3220](https://www.ti.com/product/CC3220S), which is WiFi-centric, and you'll notice for that chip (under "Features"), it lists "Secure Key Storage" (and also "Trusted Root-Certificate Catalog" for storing root certificates). Sorry for giving false hope. – Radian May 04 '20 at 17:20