Suggestions for secure authentication solution?

[mikeselectricstuff]

I have a project that requires some kind of "secure" authentication - I've skimmed a few secure authentication chip datasheets, and am overwhelmed with all the algorithms, protocols etc. as they are all multi-function devices so hard to tell how much knowledge is needed to implement with them, particularly from the provisioning side. 
 
Looking for any hints/suggestions at the general direction to look towards...

The requirements are :
There is a host and a single node, with a long wire (maybe 10-100m) connecting them.  Some host versions may talk to multiple nodes, but each will be on seperate wires. Low-level wire protocol not important now, just interested in the message content.
The host is in a secure area that is free from risk of access, the node reasonably tamper-resistant - access to the wire is the primary vulnerability. 
The host must be able to detect if the node is disconnected/tampered within about 1-2 seconds, it must be hard for anyone to fake the presence of the node by accessing the wire.
The host needs to be able to send a simple command to the node with latency <0.5 seconds, and the node must be sure it came from the host and not faked.

At installation time, there must be an easy way to pair any single individual node to the host (i.e. can't have pre-provisioned or global keys) - it can be assumed that the wire is NOT being monitored/tampered during this process. 
Ideally access is only required at the host end. The node can be in a "factory" state to allow this process to be initiated, and once completed, can only be re-paired after physical access to both ends.

Data rate and latency requirement means that the authentication data needs to be of the order of 50-100 bits.

Power consumption at the node end needs to be low ( <50mW). Power at host not an issue.
BOM cost (e.g. tiny PIC + secure chip) for both  host & node ends  <$3-4 per end in 1K qty

"How secure" is hard to answer at this stage. A simple system with everything in software in a small PIC is a possibility ( suggestions for algorithms welcome), possibly something like keeloq, however the physically secure key storage and proven algorithms of an off-the-shelf secure IC would be a very significant marketing/acceptance advantage, not to mention quicker development if the secure side can be offloaded to a seperate chip that doesn't have a huge learning curve.

Secure chips should be easily available in 1K qtys, and ideally not behind an NDA-wall - ST (e.g. STAAFE-A110) and NXP (SE050) seem good in this respect, Microchip & AD not so much.  Ideally not requiring a big blob of middleware on the host MCU.  NDA itself is not so much of an issue, more the ability to get the manufacturer to talk to you without buying huge quantites.

[ajb]

Is there any need for sort of 'root level' authentication, like to prevent other devices from pairing if someone happens to reverse engineer the algorithm? 

There are crypto ICs that support ECDH, for example microchip ATTEC608, which should make it fairly easy to get wire-level encryption to exchange a shared key during the pairing process.  From there you could use something like AES-GCM, which supports messages containing plaintext and encrypted text sections with a signature covering both -- that would allow your messages to have unencrypted headers that can still be validated by the signature, which can be handy for initial filtering/routing, IE in a bus system.

You could probably do the node -> host messages with just a simple rolling code algorithm, that shouldn't be too hard to implement even on a basic PIC, but probably easier to use the same algorithm in both directions.

[mikeselectricstuff]

Is there any need for sort of 'root level' authentication, like to prevent other devices from pairing if someone happens to reverse engineer the algorithm? 

no - the general idea of good security is that teh algorithm can be public, only the keys need to be secure

There are crypto ICs that support ECDH, for example microchip ATTEC608, which should make it fairly easy to get wire-level encryption to exchange a shared key during the pairing process.

Looks like there are a few appnotes for this chip that may be relevant - need to read those.
My initial feeling is that the "usual" way these are used is by some kind of factory provisioning process to generate keys, whearas what I need is something where random keys are generated and exchanged in the field at installation.
I'm sure this is possible but I'm out of my depth in crypto-jargon at this stage and need to figure  out the appropriate jargon for what I'm trying to do.

[ajb]

Is there any need for sort of 'root level' authentication, like to prevent other devices from pairing if someone happens to reverse engineer the algorithm? 

no - the general idea of good security is that teh algorithm can be public, only the keys need to be secure

Sure.  My question was really if you need to authenticate the device at time of pairing.  For example if someone sniffed the wire and figured out the pairing/message authentication algorithm, they could hypothetically attempt to pair a malicious device to the system.  Protecting against that would require additional measures, like preconfigured asymmetric keys or a signed certificate.  I think you can order a lot of those crypto ICs with custom key sets preloaded by the manufacturer, but if that's not a threat you're concerned about it certainly simplifies things.

My initial feeling is that the "usual" way these are used is by some kind of factory provisioning process to generate keys, whearas what I need is something where random keys are generated and exchanged in the field at installation.

Possibly, but certainly not the only use case.  Something like ECDH would allow the node and host to negotiate a key known only to those two devices even over an insecure link (it's the basis of TLS).  Once that key is established, you might be able to save it on both devices and use it as the permanent encryption/signing key for all future messages.  Or you could use the ECDH key to securely exchange a new permanent key or pair of keys.  Generating the keys shouldn't be too difficult, any crypto IC that can do ECDH should be able to generate keys.  Once both devices have that single shared key, or each has a copy of the other's key, you can choose from any number of cryptographic algorithms for all of the post-pairing messages.

[mikeselectricstuff]

Is there any need for sort of 'root level' authentication, like to prevent other devices from pairing if someone happens to reverse engineer the algorithm? 

no - the general idea of good security is that teh algorithm can be public, only the keys need to be secure

Sure.  My question was really if you need to authenticate the device at time of pairing.  For example if someone sniffed the wire and figured out the pairing/message authentication algorithm, they could hypothetically attempt to pair a malicious device to the system.  Protecting against that would require additional measures, like preconfigured asymmetric keys or a signed certificate.  I think you can order a lot of those crypto ICs with custom key sets preloaded by the manufacturer, but if that's not a threat you're concerned about it certainly simplifies things.

Yes, we absolutely need to authenticate at time of pairing - to take any factory-fresh node device out of the box, connect it, and tell the controller to pair it. Obviously there are potential issues around de-pairing/re-pairing that need to be thought about but not a major consideration as the pairing process can only be initiated from a secure location.
 
Fortunately we can assume that the wire is secure during pairing, and that no bad actors will have access to the controller at any time - this simplifies things but also makes it a little different from a more typical application of security chips. I have no doubt that most chips can do it, it's really about getting my head round what the process would look like. 

[NorthGuy]

I don't think you need a secure chip. Simple security algorithms can be implemented on nearly any MCU.

You need to start from the list of attacks that you want to prevent, such as:

- when pairing, you want your node to somehow authenticate itself to the host so that the host know this is one of your nodes.

The attacker may -

  - sniff the pairing process and use it to create his own nodes
  - sniff communications of the paired node and retrieve something that can be then used for pairing a new node
  - physically open the node and retrieve the key which then can be used for pairing
  - pretend to be a host and engage into a fake pairing process with unpaired node to figure out how to pair
  - pretend to be a node and try to pair with the host, possibly many times every second
  - etc etc

The more you think of the better.

Then you get to the next step:

- host needs to authenticate itself to a node (whether paired or not)

An attacker can ...

And so on until you cover all the things that you want to secure.

Then you design security protocol which make all of these attacks impossible, or at least as difficult as you can.

If such process sounds difficult, this is because it is. No amount of algorithms or security chips will help if you leave at least one of the attack venues open. That is how real things get compromised.

That said, the probability of actual attack may be very low. Therefore, you can provide "fake" security, which is enough to scare amateurs even though it has no chance in case of real attack. Bit if there's no real attacks, what difference does it make?

[jbb]

Getting a pre-cooked authentication IC may be the best way forward here.  Although it's intended for heavier duty, using a TLS library may be a good way forward here.

I had some thoughts about anti-removal detection:

• you could send a heartbeat message through the secure channel
• this implies that the host & nodes will be powered on continuously - are they battery powered? If not, what about power cuts?
• make sure the client really wants this feature. It's going to be a pain, with false tamper detections and trips to fetch the disconnected node and bring it back to the shack for re-pairing. Given some of your very cool installation work is installed 10 meters above the ground, such trips could be a giant pain in the backside.

Regarding cryptography:

• If you're prepared to 100% trust that there aren't any eavesdroppers on the wire, you can do quite basic pairing.
• If you want to authenticate that the Node is an authentic MikesSecureStuff Node, it will need some kind of certificate inside. This will need secure loading at the factory (see below) but should allow secure pairing over an untrusted wire (yay!)

Building a Node @ factory

• Generates an asymmetric key pair e.g. Elliptic Curve Cryptography (ECC) public and private key
• Sends the public key to a Hardware Security Module (HSM) computer in the factory (this may be air-gapped and placed in a secure cage), which makes a certificate to say 'the above private key is indeed a genuine MikesElectricStuff widget'
• Stores the public key, private key and certificate in secure EEPROM
• Runs a TLS server, ready for the Host to connect

Building a Host @ factory

• Gets loaded with the a number of trusted HSM certificates in the factory
• Optionally, generate an asymmetric key pair and get a certificate (same procedure as for node)
• Stores the (optional) public and (optional) private key and list of HSM certificates in secure EEPROM or something
• Runs a TLS client for each Node connection.  When connecting to the Node, the TLS library will verify the Node certificate against the list of HSM certificates.

[mikeselectricstuff]

I don't think you need a secure chip. Simple security algorithms can be implemented on nearly any MCU.

I agree it may not be necessary, but using a  ready-made solution may be cheaper - would probably allow a smaller MCU if all the crypto is offloaded, and also as mentioned, being able to point to a known & proven crypto standard will help acceptance (customers would likely include Government types who like these boxes ticked) 

You need to start from the list of attacks that you want to prevent, such as:

- when pairing, you want your node to somehow authenticate itself to the host so that the host know this is one of your nodes.

The attacker may -

  - sniff the pairing process and use it to create his own nodes
  - sniff communications of the paired node and retrieve something that can be then used for pairing a new node
  - physically open the node and retrieve the key which then can be used for pairing
  - pretend to be a host and engage into a fake pairing process with unpaired node to figure out how to pair
  - pretend to be a node and try to pair with the host, possibly many times every second
  - etc etc

Yes it is important to consider threats, and many of these have been eliminated by the way the system is installed and used
I already mentioned that we are not concerned about wire security during pairing due to the  installation process. Pairing will always be initiated from a secure location so an attacker can't pair a new node. If the node is physically opened then the whole system is already compromised, but we'd want the host to detect that.
The attacker would potentially have access to unpaired nodes, but as the pairing would be initiated from the host in a secure area, these would be of negligible use.   

- host needs to authenticate itself to a node (whether paired or not)

A node will always be paired as part of the installation process, so authenticating the command from host to node  could  be done by signing, or a reverse challenge-response

Then you design security protocol which make all of these attacks impossible, or at least as difficult as you can.

If such process sounds difficult, this is because it is. No amount of algorithms or security chips will help if you leave at least one of the attack venues open. That is how real things get compromised.

That said, the probability of actual attack may be very low. Therefore, you can provide "fake" security, which is enough to scare amateurs even though it has no chance in case of real attack. Bit if there's no real attacks, what difference does it make?

For this application,  the overall security protocol is fairly simple as many risks have been eliminated by design/installation procedure. The key thing is authenticating messages, and risk is low, but an important requirement may turn out to be being able to quote some specs/standards/encryption schemes that will tick boxes for the customer

[mikeselectricstuff]

Getting a pre-cooked authentication IC may be the best way forward here.  Although it's intended for heavier duty, using a TLS library may be a good way forward here.

I was thinking a security chip + small MCU may be cheaper/easier than an MCU capable of doing TLS or other security in software. The node will be doing nothing else but replying to auth requests and setting an output on receipt of a command.

I had some thoughts about anti-removal detection:

• you could send a heartbeat message through the secure channel

The host will continuously poll the node

• this implies that the host & nodes will be powered on continuously - are they battery powered? If not, what about power cuts?

Yes they will be continuously powered, with system-wide backup. Power at the node is limited due to being on the end of a long wire which may be part of existing cabling which we can't re-specify

• make sure the client really wants this feature. It's going to be a pain, with false tamper detections and trips to fetch the disconnected node and bring it back to the shack for re-pairing. Given some of your very cool installation work is installed 10 meters above the ground, such trips could be a giant pain in the backside.

Yes, they want something - the product will be to retrofit existing/new installs solely to add this specific feature.

Regarding cryptography:

• If you're prepared to 100% trust that there aren't any eavesdroppers on the wire, you can do quite basic pairing.
• If you want to authenticate that the Node is an authentic MikesSecureStuff Node, it will need some kind of certificate inside. This will need secure loading at the factory (see below) but should allow secure pairing over an untrusted wire (yay!)

Building a Node @ factory

• Generates an asymmetric key pair e.g. Elliptic Curve Cryptography (ECC) public and private key
• Sends the public key to a Hardware Security Module (HSM) computer in the factory (this may be air-gapped and placed in a secure cage), which makes a certificate to say 'the above private key is indeed a genuine MikesElectricStuff widget'
• Stores the public key, private key and certificate in secure EEPROM
• Runs a TLS server, ready for the Host to connect

Building a Host @ factory

• Gets loaded with the a number of trusted HSM certificates in the factory
• Optionally, generate an asymmetric key pair and get a certificate (same procedure as for node)
• Stores the (optional) public and (optional) private key and list of HSM certificates in secure EEPROM or something
• Runs a TLS client for each Node connection.  When connecting to the Node, the TLS library will verify the Node certificate against the list of HSM certificates.

Pretty much none of that is needed - Security starts at the on-site installation stage, nodes are potentially freely available, pairing is initiated on the host in a controlled environment, and the host-node connection is not regarded as vulnerable during pairing. How this may work for extra-paranoid customers is the node is connected  locally to the host for pairing, then moved to the final location at the end of the wire.

Part of my problem is wading through all the features of the crypto chips to distill out  what we actually need without spending too much time learning unnecessary things.
The on-site pairing is what I see as the main difference between this and the more traditional factory provisioning/certificate process, none of which is needed here.
At installation we just need the host to generate a random key, communicate it to the node and store it securely in the node.
 
Like I said the need for "crypto" is mostly about using a cheap off-the-shelf chip, and ticking boxes for customers who have no clue about the technicalities. 
We could do it just fine with some mildly obfuscated CRC type stuff on a PIC8, but for the intended market, it is probably worth spending half a buck to be able to tick those boxes, and be confident we won't end up the subject of a Defcon presentation!

[shabaz]

It's been ages since I looked at it, but Maxim's DeepCover solution might be a possible candidate. Unfortunately some docs are NDA'd, but it wasn't too difficult to get hold of them by submitting a request, but I can't recall the precise steps. Probably some case needs to be raised when logged in.

The Maxim solution is intended for things like printer ink cartridge authentication. The host and sensor use 1-wire (a protocol I barely know, so I'm not aware if it can be extended to 100m by say sending it over some other physical link).

There are two DeepCover chips, one for host, and one for node. Both are programmed with a secret, from the host microcontroller (which communicates to the host DeepCover chip via I2C).

Then, the host microcontroller can periodically send random challenges whenever desired (and the host DeepCover chip will forward it to the node), and both the host and node will compute a hash from that challenge, and the node will send its hash to the host DeepCover chip for comparison.

The attached diagram shows how things connect. However, that node chip in the diagram is for things like printer ink usage storage in on-chip memory, and cannot externally control other devices within the node. But, there are other node chips within the range, e.g. this one looks like it may have GPIO: https://www.analog.com/en/products/ds28c36.html
Unfortunately I've not used that chip.

The datasheets on the AD/Maxim site are almost entirely useless since they have deleted everthing apart from a fraction of the first page, but it may be worth it to request the full datasheets for all the possible DeepCover chips that have a chance of being usable.

[jbb]

All right, so you’ll need hardware with a True Random Number Generator (TRNG), AES, reliable JTAG lockout, and preferably an Elliptic Curve Cryptography (ECC) module.

Ten years ago this would have been hard to find. Thankfully, these days it’s becoming quite common. Which should hopefully save you from the aggravation of an NDA. Maybe an EFM32 Jade Gecko would suit?

Re JTAG lockout; this has been a problem for several microcontroller lines. Sometimes people don’t lock it (oops), sometimes workarounds have been found (eg power glitch attacks).

I used to work at a payment company and we used microcontrollers with different part numbers for no-JTAG and yes-JTAG parts (not sure if they blew a fuse at factory or something more dramatic). So prototypes with JTAG debug were special order.

[jbb]

Sorry, forgot to say @ start of comment…

If you want to do some nice box ticking, a separate crypto chip (usually with branding like ‘secure enclave’ or what have you) plus TLS communications is probably a good way to hit the buzzwords.

If you want to do it simpler, a microcontroller with TRNG, AES and ECC hardware would likely be quicker to develop.

If this has potential as a product, you could do the simple one first and then the fancy one later.

[NorthGuy]

I don't understand why you need a pairing process at all. Simply install the same "secret key" on both the host and the node by your own means. Then generate encryption keys from the "secret key" combined with random input from both parties and use this encryption key with some sort of symmetric encryption such as AES. Make sure the random input is re-generated frequently and never repeats. If the keys don't match, the other part will receive garbage. You can easily verify genuinity by sending predetermined message and see if it arrives intact to the other end. This solves authentication problem.

Store the "secret key" for every host you ever made in the factory and simply implant it into a new node when you want to pair with a known host. Or vise versa.

This way you totally avoid pairing process which is inherently insecure.

[DrGeoff]

What's the comms protocol? It sounds like you control both ends, so I assume you also have control over the messaging protocols and formats (APDU)?
You may be able to build the security into the messaging protocol using pre-placed symmetric keys (eg AES-256) and include the selected key number in the header of the message.
The use of small 8-bit devices in endpoints allows the use of symmetric algorithms such as AES quite easily.

[Marco]

I don't understand why you need a pairing process at all. Simply install the same "secret key" on both the host and the node by your own means. Then generate encryption keys from the "secret key" combined with random input from both parties and use this encryption key with some sort of symmetric encryption such as AES. Make sure the random input is re-generated frequently and never repeats.

Replay attacks?

rfc9528 was just finalized, there's a Rust implementation on github :p

[mikeselectricstuff]

I don't understand why you need a pairing process at all. Simply install the same "secret key" on both the host and the node by your own means.

Because both host and node need to be products that are held as stock items and paired as part of the installation process. 

[mikeselectricstuff]

What's the comms protocol? It sounds like you control both ends, so I assume you also have control over the messaging protocols and formats (APDU)?

comms protocol is a seperate issue - I can deal with that, it's just the content of the messages I'm trying to get my head round.

[mikeselectricstuff]

Microchip SHA104/SHA105 and ATSHA204 look interesting from the cost point of view ( £0.30).

Having looked at a few devices now, seems pretty much any crypto chip can do the job so I think I'll explore these to start with based purely on cost and availability.

The latter looks like it has a full datasheet available, so will read through that & see if I can get my head round this...!
 

[Marco]

So basically you want a preshared key to make sure only official devices can pair and the during pairing create a new key just for the local security?

How do you want to do the pairing? Button press on both devices?

[mikeselectricstuff]

So basically you want a preshared key to make sure only official devices can pair and the during pairing create a new key just for the local security?

No, the key generation and sharing happens at the pairing process. prior to that, all hosts and nodes are "blank" and we don't need to care about them being "official"

How do you want to do the pairing? Button press on both devices?

The pairing process happens in a secure environment, so the nodes (and a new host) can initially be 'blank'.
The pairing process would be to connect a node to the host, and press a button on the host. The host would generate and store a random key, transfer it to the node and store it there ( or vice versa - doesn't matter). This key transfer does not need to be protected.

From then on, only that node will provide a correct response to a random challenge from the host, so if the node was disconnected, or swapped with another node, this can be detected. 

The requirement for the host to send a command to the node is a secondary requirement, and I think can probably be done by a reverse authentication initiated by the node.

Replay attacks are not an issue as the host will always issue a random challenge to the node.

[Marco]

Given the specialized provisioning and no need to deal with replay, rolling the protocol yourself does seem the way to go (with or without a cryptochip). Though crypographers really hate it when you do that.

[NorthGuy]

I don't understand why you need a pairing process at all. Simply install the same "secret key" on both the host and the node by your own means. Then generate encryption keys from the "secret key" combined with random input from both parties and use this encryption key with some sort of symmetric encryption such as AES. Make sure the random input is re-generated frequently and never repeats.

Replay attacks?

That's why you use random input. The host supplies his random data which is then used in encryption key generation. The node does the same. This ensures that the encryption key is different for every session. Next time the host will give you a different random number, the encryption key will be different. The node will use different random numbers too. Therefore neither the host not the node can replay older sessions or any parts of older session.

The pairing process is much bigger concern. The very existence of the pairing process implies that an untrusted party can implant secret keys into the device. This mechanism can be exploited.

[NorthGuy]

Though crypographers really hate it when you do that.

And Linux developers really hate when you write your own drivers for their kernels. Everyone wants to be in control

[mikeselectricstuff]

I don't understand why you need a pairing process at all. Simply install the same "secret key" on both the host and the node by your own means. Then generate encryption keys from the "secret key" combined with random input from both parties and use this encryption key with some sort of symmetric encryption such as AES. Make sure the random input is re-generated frequently and never repeats.

Replay attacks?

That's why you use random input. The host supplies his random data which is then used in encryption key generation. The node does the same. This ensures that the encryption key is different for every session. Next time the host will give you a different random number, the encryption key will be different. The node will use different random numbers too. Therefore neither the host not the node can replay older sessions or any parts of older session.

The pairing process is much bigger concern. The very existence of the pairing process implies that an untrusted party can implant secret keys into the device. This mechanism can be exploited.

Once again, this is not an issue. The pairing process only ever occurs in a secure location, initiated manually on the host.

The only threats we care about are :
 Someone accessing the wire and disconnecting the node without the host knowing about it ( i.e.being able to sniff the wire and derive the key, and then emulate the presence of the node)
 The node only responding to a command that it can be sure came from the host.

[ajb]

If you're really okay with doing the initial key exchange in plain text and don't need to authenticate the devices attempting to pair, then things do get a lot simpler.  All you really need at that point is a message signing algorithm -- although encrypting a message can provide that implicitly, since a message won't be valid if encrypted/decrypted with mismatched keys.

Aside from the pairing process, you will need to do some randomization of each message.  Encrypting very similar plaintext with the same key and initial conditions can allow an attacker to start deducing the key.  You can address this by using a randomized 'initialization vector' for each message.  The IV doesn't need to be secret, just unique for each message.  That ensures that the same plaintext never produces the same ciphertext. 

To prevent replay attacks in both directions (spoofing device presence, or injecting unauthorized commands) you'll need to have the devices exchange some sort of ephemeral data, which can probably be packed into the normal messages.  One simple approach would be to have each message include a new randomized nonce plus the last nonce received from the other device in the signed portion of the message.  The receiver would just need to check that each message includes the last nonce it sent (or perhaps the previous one, if messages can cross on the wire you'd want to be able to handle that case), and store the sender's new nonce for use in its next message.

Given the specialized provisioning and no need to deal with replay, rolling the protocol yourself does seem the way to go (with or without a cryptochip). Though crypographers really hate it when you do that.

Well, there's a big difference between rolling your own crypto algorithm and rolling your own message protocol (or file format, or whatever) that uses an established algorithm/implementation.  There are definitely ways of employing crypto that reduce/eliminate its effectiveness, but with an application as simple as this one it shouldn't be too hard to get it right.