Copyright ©

Mongoose OS Forum


ATECC508A - production deployment config

blublablubla United States

Hey guys, hope all is well.
I was reading the docs and saw that the crypto chip example is not meant for production. I took a look at the Microchip documentation, but even after going through everything, I'm still not sure what's a safe configuration. If I may ask, is there a one-size-fits-all config? If not, what should I be paying more attention to?



  • rojerrojer Dublin, Ireland

    particular issue with the config we provide is that it allows private keys to be re-generated and rewritten with arbitrary keys (the chip never allows reading of private keys, so at least there's that).
    this is deliberate - this allows re-generating and re-writing keys without burning through chips during development.
    however, this also makes it unsuitable for production.

    when preparing a production configuration, you need to decide whether you want keys to be generated at all, whether you want to allow them to be written (set to a particular value), maybe put a limit on the number of uses for the key. there isn't a one-size-fits all config, as the chip can do so much and is so flexible.
    perhaps if you describe what you want the chip to allow to be done in production, i can suggest a config.

  • blublablubla United States

    Thanks for your prompt reply rojer. I'll read some more on it and I'll come back!

  • blublablubla United States

    Rojer, are you able to provide me with a config that's security-first? Once the AWS keys are set for the device, they stay there for the lifetime of the device.

  • Are you sure that's what you want? If you are using ECDHE, it is more secure to use fresh ephemeral keys each time, as there are attacks that can exploit repeated use of the same AES key derived from the private key. As well, there are other vulnerabilities and trade-offs that you want to consider for your own application. It may not be as simple as "lock it all down".

  • rojerrojer Dublin, Ireland
    edited May 2017

    yeah, i think keeping a couple slots for ECDHE use is advisable. i doesn't really compromise security of the main key.
    probably in this case we want to individually lock the main key slot after writing. i need to experiment some, i'll get back to you on this a bit later.
    or maybe @carl can suggest something.

  • That's what I've been leaning toward. A couple of locked slots for long-term identity (internally generated), and others unlocked (lockable=false) for ECDHE and replaceable public keys. I haven't gone full-bore with encrypted reads, etc., but what's nice about this chip is that is has so many options, but it takes some time to figure them all out, especially without a full datasheet.

  • blublablubla United States

    Hey thanks for your input guys.
    I'm still here learning the basics of the ECC508A and cryptography still. Because I am still unsure what I really need, I'll gladly go with what you suggest while I'm here getting more info!

  • What are you trying to do, just TLS? Or do you have other signing, verifying and/or encryption you want to do?

  • blublablubla United States

    Yea, mainly TLS for the MQTT messages. Don't have anything in mind yet as to what else to encrypt.

  • carlcarl US
    edited May 2017

    So the example config is reasonable enough for what you want to do. Where you can run into security issues is in how you manage the keys and the signed data. Specifically, rather than generating the secret key with openssl, you can have the chip generate it, and have it report its public key. You will also want to lock that slot, so a new key can't be generated there, or worse, have one written to it. Of course, the whole point of have a client-side cert (and key) is to do mutual TLS, so you want to configure your server to know about it. I'm not sure how people do this at scale, but that's one of the challenges of PKI in IoT, I suppose.

    The other part is in regards to managing the data being written to and read from the chip. If it's sensitive, and you are concerned about someone probing the i2c lines to read it, you will want to encrypt reads and write to/from the chip. What's nice is that the ESP32 has a way to burn in a 256-bit AES key, and use it for encryption/decryption without reading it directly, as I understand. The ATECC508A can also have this key burned into a slot and locked down, and then used for its communication. I haven't tried this, but would be interested in what you find. And with ECDH support in the chip, you can encrypt a message to your server in addition to sending it over TLS, or encrypt it to some ultimate endpoint, if you have their public key. The upshot of all this is that you can have sensitive data generated within the MCU that never sees the light of day (unencrypted) until the final consumer decrypts it.

    Hope that helps!

  • blublablubla United States

    Thanks a lot @carl . When I'm done I'll come back here with the results :)

  • blublablubla United States

    I was wondering, if you use ESP32, would you still need the 508A? You'd encrypt the flash so there's no way to read the keys.

  • With 508A, you can sign without reading the keys. So you get non-repudiation.

  • blublablubla United States
Sign In or Register to comment.