Implement support for hardware RNG device(s) #55

New Issue

Open

opened 2024-12-04 13:53:25 +00:00 by anton · 0 comments

anton commented

2024-12-04 13:53:25 +00:00

Owner

There are several devices which can be used as an additional source of entropy such as:

Secondary computer with different chip architecture from primary workstation which can generate entropy and save it to a file (RISC-V, FPGA, HSMs etc.)
Quantis QRNG USB
TrueRNG
Infinite Noise TRNG

It appears that most of these devices have the ability to write entropy to a file. This is convenient because it means we can just implement functionality that uses the file + OS entropy for cryptographic actions, rather than implement interfaces for specific devices.

This would also allow the use of a photograph as a source of entropy. Ideally we can pass multiple files as additional entropy.

Threat Modeling

There is the risk of supply chain / bad usb style attacks here so in the context of managing cryptographic material so we need to ensure a few counter measures.

Use "chain of custody" principles / processes
Use anti-interdiction where/if available
Inspect hardware physically if possible
Use devices to seed entropy to a USB, then wipe system. In other words never plug in the device while cryptographic actions are being performed - primarily to avoid entropy issues as a bad USB could do a libfakerand style attack.

There are several devices which can be used as an additional source of entropy such as: * Secondary computer with different chip architecture from primary workstation which can generate entropy and save it to a file (RISC-V, FPGA, HSMs etc.) * [Quantis QRNG USB](https://www.idquantique.com/random-number-generation/products/quantis-random-number-generator/) * [TrueRNG](https://ubld.it/truerng_v3) * [Infinite Noise TRNG](https://www.mouser.ca/new/leetronics/leetronics-infinite-noise-trng/?srsltid=AfmBOoohQ1xV1EbUfZwS01VMIgx_Ot7x5aDpLtrpRfNjj8SzAOumB5it) It appears that most of these devices have the ability to write entropy to a file. This is convenient because it means we can just implement functionality that uses the file + OS entropy for cryptographic actions, rather than implement interfaces for specific devices. This would also allow the use of a photograph as a source of entropy. Ideally we can pass multiple files as additional entropy. ## Threat Modeling There is the risk of supply chain / bad usb style attacks here so in the context of managing cryptographic material so we need to ensure a few counter measures. * Use "chain of custody" principles / processes * Use anti-interdiction where/if available * Inspect hardware physically if possible * Use devices to seed entropy to a USB, then wipe system. In other words never plug in the device while cryptographic actions are being performed - primarily to avoid entropy issues as a bad USB could do a `libfakerand` style attack.

anton added this to the Custody Framework project 2024-12-04 16:37:26 +00:00

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: public/keyfork#55

No description provided.