Sending "Private Key" Over Internet?


#1

On the following page…
http://docs.exosite.com/tutorials/provisioning/

You have the option of creating a “Private Key” to authenticate. You then require SENDING YOUR PRIVATE KEY OVER THE INTERNET (X-Exosite-CIK header)! This is WRONG, WRONG, WRONG!

NEVER, NEVER, NEVER expose your private key on the network. Private keys should be extremely secure, with limited permissions, password protection, etc.

If I understand the process, we are creating a symmetric (shared) key, not a private key. If this agrees with your intention, would you correct the verbiage in your application?


#2

@atp

I think there is some confusion on how devices authenticate with Exosite. In Murano there is way to use a proper private key, as in public key cryptography, or you can use an Exosite device authentication token. The method using the vernacular of a “private key” is TLS client certificates and the other is the the One Platform backwards compatible device authentication token method.

You are right, in the authentication token model a key will be generated in the server and then sent over the internet to the device. The device is then expected to present this key in a custom header in order to authenticate requests made of the device HTTP API. This is why for production devices we by default expect devices to connect with us through TLS. Without getting a hold of us to talk about why your hardware or solution cannot support, or has a good reason not to support TLS, we do not allow our customers to deploy devices at scale on unencrypted communications.

However if your Solution has no need to be backwards compatible with an existing connected product deployed on Exosite’s software, then you should seriously consider implementing the TLS client certificate authentication model. This is Exosite’s recommended authentication scheme, and if setup properly the private key will never leave the memory of the physical device. I think that this method is much more in line with the standards you were worried that we were violating.

Let me know if this answers you questions and concerns. I am perfectly happy to talk to you about how the provisioning models work and to specificly address concerns that you may have.

Happy to help,
-Martin


#3

This is what I am referring to…

Please change this verbiage, since it is confusing and incorrect.


#4

Great! That looks like a minor consistency change in our UI. I’ll get a hold of the development team to let them know.

Thanks,
-Martin


#5

Thanks for addressing this, but don’t understate the effect of these problems.

It’s a significant mistake.


#6

Hey @atp,

Your last post indicated a plurality of problems, but I thought we had discovered that Exosite could be more clear in its use of vernacular in our UI.

I am not clear yet on what you mean. Are you referring to the possible misconception of applying the label “private key” to the device authentication token scheme, or have you encountered something else?

Happy to help,
-Martin


#7

The tangible issue is the terminology misuse in the UI. If you can take care of it, that would be fantastic.

Cheers.


#8

Hi @Martin

Are there any project references that authenticate with Murano based on keys and certificates stored in hardware crypto ICs (eg. TPM 1.2, TPM 2.0, ATECC508A)?

Kind regards,
Vijay.


#9

@atp - Sounds good.


@Vijay I do know of a prototype implementation with the ATECC508A. I’ll ask the developer working on it where things are at. Microchip is one of our partners; When the project is ready we will probably release it with some fanfare.


#10

That sounds great! Are there any plans to integrate this with GWE?
Right now, we need to edit GWE configuration file to point to the private key and certificate. But, if this chip were used, the private key is “truly” hidden.

If you have any details about how the provisioning flow occurs with this chip in place, please do share with me.
Also, is there any commercial off-the-shelf gateway solution which has this chip already installed?

Kind regards,
Vijay.


#11

@Vijay

I don’t think we have any hardware partners that have released a product that is both compatible with GWE and has the ECC508 or other crypto chip in it. Once we are aware of such a machine, making GWE compatible with that type of private-key crypto hardware would definitely be on its roadmap.

I talked to the Application Engineer who is working on getting the Atmel SAM G55 and my understanding is that he has it working with our development environment. I don’t have a timeline to share, but a proper example should come out this year.

If you have any details about how the provisioning flow occurs with this chip in place, please do share with me.

Instead of trying to relay information, I’ll ask our engineer to make an account on this forum and post. Playing telephone just threatens to degrade communication.

-Martin


#12

@Martin

I got the Atmel recommended kit for testing ATECC508A. This along with the socketed daughter board can be used to demonstrate complete provisioning workflow. Atmel has also provided the application note and full source code to get this setup up and running. I’m not sure if this is what you are trying to do with the SAM G55 board.

If either this chip or the TPM 2.0 hardware is supported by the GWE, then we can go ahead and start testing this solution. There are many off-the-shelf commercial gateways that already come with the TPM2.0 chip by default. We want to take advantage of these hardware based cryptoauthentication devices.

I’d love to interact with the engineer working on this from your side. I agree on the last comment!

Kind regards,
Vijay.


#13

@Vijay,

My understanding is that we are trying to do something similar and treat the generated certificate as the device’s identity.

I am pretty sure that the current dev kits that support the ATECC508A are not beefy enough to run GWE. GWE is pretty memory hungry and none of the kits in that family I could find in a quick search meet our flash/disk or memory requirements.

I know that it is possible to pare down what is installed with GWE, typically that includes not using GMQ. Also you could probably squeeze past the published GWE requirements, but I wouldn’t recommend it. We couldn’t guarantee the performance of GWE. I also think that those kits are beyond the bounds of possible GWE squeezing to get it to work on that chip.

-Martin