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...

  • $\begingroup$ Do the devices have some pre-established relation (like a shared key or some public-key certificate issued at production time)? Are there any computational restrictions here (ie can these devices run standard asymmetric crypto with sensible parameters)? $\endgroup$
    – SEJPM
    Commented Jul 30, 2017 at 21:37
  • $\begingroup$ We can initiate some kind of pre-established relation prior to running IO's. But again not sure what should be done during this pre-established relation phase that can later be used for encryption $\endgroup$ Commented Jul 30, 2017 at 21:47
  • $\begingroup$ For example you can issue certificates to the devices prior to deployment and thus authenticate devices this way, essentially turning you into a CA. Would you also please expand the acronym IO? I'm quite unsure what it means. $\endgroup$
    – SEJPM
    Commented Jul 30, 2017 at 22:01
  • $\begingroup$ I Am sorry that I have to ask many questions as I am new to Encryption subject. How does issuing certificated prior to deployment help in exchanging keys across two systems ? $\endgroup$ Commented Jul 30, 2017 at 22:27

1 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.

  • $\begingroup$ ... And if you really have no clue what this all is about, you probably want to hire / contract a proper cryptographer (or some proper crypto-services company) and work out all the details for you better than some random potato on the internet in 5 paragraphs. $\endgroup$
    – SEJPM
    Commented Jul 30, 2017 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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