You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A Digital Signature is used to verify the authenticity and integrity of a message using a cryptographic algorithm.
This can be used to validate a device’s identity to a server, or to check the integrity of a message.
The Digital Signature (DS) module provides hardware acceleration of messages’ signatures
based on RSA. It uses pre-encrypted parameters to calculate a signature. The parameters are encrypted using
HMAC as a key-derivation function. In turn, the HMAC uses eFuses as an input key. The whole process happens
in hardware so that neither the decryption key for the RSA parameters nor the input key for the HMAC key
derivation function can be seen by the users while calculating the signature.
Support
If a cell contains am em dash (—) this means that the particular peripheral is not present for a chip. A check mark (✓) means that some driver implementation exists. An empty cell ( ) means that the driver hasn't been implemented for the chip yet.
With this functionality, these devices can implement some form of 2FA or act as a HSM which would be a huge bonus. I'm a cryptographer myself, and would be more than willing to give writing a Rust-compatible challenge-response library utlising these features. Maybe an esp-2fa crate perhaps, which can handle challenge-response?
I only have access to ESP32-S3's (as they're my favourite), but I'll pick up a few other suitable chips in order to validate things across more devices in due course.
I've been wanting to make my own HSM out of an ESP32-S3 - I've already made a hardware-based password manager (it's just an Adafruit ESP32-S3 Feather TFT soldered onto a custom PCB with 3 buttons. You're able to use left/right to iterate between keys, and enter them via HID emulation). It lacks encryption or some form of protection at the moment, which is why I haven't published it yet.
I do have a few cryptographic co-processors which would do the trick, but being able to do it with an off-the-shelf device would make this much more accessible to the everyday user!
On another (non ESP related note), I picked up a Tufty 2040 which has a total of 6 user buttons - the total permutations for say an 8 digit PIN to unlock the device would be 6^8 (1679616). This, combined with a KDF of sorts, would be pretty secure alone (although the ESP32 devices would be far more suitable due to the additional cryptographic extensions).
Description
A Digital Signature is used to verify the authenticity and integrity of a message using a cryptographic algorithm.
This can be used to validate a device’s identity to a server, or to check the integrity of a message.
The Digital Signature (DS) module provides hardware acceleration of messages’ signatures
based on RSA. It uses pre-encrypted parameters to calculate a signature. The parameters are encrypted using
HMAC as a key-derivation function. In turn, the HMAC uses eFuses as an input key. The whole process happens
in hardware so that neither the decryption key for the RSA parameters nor the input key for the HMAC key
derivation function can be seen by the users while calculating the signature.
Support
If a cell contains am em dash (—) this means that the particular peripheral is not present for a chip. A check mark (✓) means that some driver implementation exists. An empty cell ( ) means that the driver hasn't been implemented for the chip yet.
Additional information
Here's an example of how the peripheral is used inside
esp-idf
to accelerate signatures formbedtls
https://github.com/espressif/esp-idf/blob/master/components/mbedtls/port/esp_ds/esp_rsa_sign_alt.c
The text was updated successfully, but these errors were encountered: