Secret Key Exchange and FIPS or Industry Standard Compliance

Question

I am trying to collect several information regarding Security Industry Standards and the FIPS compliance to meet the security standards for our future development system.

In this case, we have two systems connected each other point to point through switch. We are interested in encrypting the data to run IO's across these two systems. Planning to encrypt data with AES-128, but struct on the best Industry standard compliance algorithsm to exchange the Symmetric Key. We are not connected here to Internet to exchange keys through 3rd Party or any other Certificate Authority.

Could someone please suggest the best possible way to generate and exchange keys in this scenario and also meet the industrial standard ?

Thanks a lot in advance...

Answer 1

Suppose you are a device manufacturer. Suppose further you know to which companies you are selling your devices. Suppose further that all that really matters for the device-to-device communication is a) that they are legitimate devices made by you and b) that they are operated by a specific company. Now if your customers trust you (which they kinda have to given that you sell them devices), these devices can be made to communicate securely.

I'll make the assumption that the static private keys are non-extractable because if you can extract one, you can impersonate this device. This can be achieved using TPMs, HSMs or other security-chip based key-stores.

---

The idea here is that you pre-provision all devices you ship and you essentially act as the CA in this ecosystem.

The setup is really quite simple:

1. Manufactur the device right up to the point where you would normally ship it (that is all hardware and software is complete)
2. Generate an asymmetric signature key-pair on the device. Also generate a CSR on the device, given that you create the CSRs in a trusted environment, you can include the designed customer in it.
3. Transport this CSR to your internal CA and issue the requested certificate. Given that the CSR is from a trusted environment, you can "blindly" copy the owner information into the certificate.
4. Transport and install the certificate into the secure-chip's keystore. Also install the certificate / public key of your internal CA into your platform's root CA store (and make sure it's the only root CA) on the device. Make sure that your preferred SSL/TLS library actually uses this key-store.

This is the whole setup, which needs to be executed per-device.

Now for the connection establishment which is really standard.

1. Suppose Device A wants to securely talk to Device B. Suppose further both devices are listening for incoming connections.
2. Now A ("the client") initiates a TLS handshake with B ("the server").
3. You run a standard TLS-connection between the two devices with the following caveats:
   1. You make sure only secure parameters and cipher suites are used.
   2. You only accept B's certificate if it passes standard certificate validation and your custom company-based validation and it is issued by your root CA.
   3. B needs to request client-authentication during the handshake. B needs to only accept A's certificate if standard validation succeeds and it passes the custom company-based validation and it is issued by your root CA.

And that's it. Your devices now have a secure connection and they know (and only that!), that their communication partner was manufactured by you and that their communication partner is a device that was sold to the given (other?) company.

The use of the device-manufacturer CA is industry-standard, as well as the use of TLS here. For high confidence you may want to your customers to use their own CA, their own sub-CA (and filtering for that one then if requested) and you want to apply standard CA security practices to your device-authentication CA.