search

GaloisInc / BESSPIN-CloudGFE

The AWS cloud deployment of the BESSPIN GFE platform.
Apache License 2.0
2 stars 2 forks source link

RNG in HSM #34

Open kiniry opened 4 years ago

kiniry commented 4 years ago

robert.watson - 03:06 This is actually a more interesting general question .. I think FETT will need a decent RNG. I can’t remember if there’s a VirtIO entropy model/driver/service. I think Xen has one?

I think as long as you reference this comic in this a comment, you can do whatever you want for an RNG: https://xkcd.com/221/

@kiniry: A decent entropy source in CloudGFE would be a very useful thing.

kiniry - 08:57

It has already been a point of discussion. We had done some development on an async RNG on another project and considered using it for the (Cloud)GFE HSM, but it isn't good enough yet. We do have AES in the HSM, so could could just create a DRBG using that. @dmzimmerman, what do you think? I've filed an issue to reflect upon it.

rtadros125 commented 4 years ago

CC @rod-chapman

rod-chapman commented 4 years ago

The OTA service doesn't any sort of TRNG, but I suspect the HTTPS-on-TLS will. For FreeRTOS, we need to implement some internal functions inside mbedtls to access a source of entropy. For Debian and FreeBSD, I assume we'll need some sort of device driver that exposes entropy to /dev/urandom or whatever it is. When you build mbedtls on UNIXy platform, I think it defaults to using /dev/urandom ...

dmzimmerman commented 4 years ago

I think it'd be fine to use the HSM for a DRBG... HMAC_DRBG would likely be faster than using AES with CTR_DRBG, I'd think (though that's just a guess on my part); also, HMAC_DRBG has a machine-verified security proof out there, for whatever that's worth, and I don't know if CTR_DRBG does.

rwatson commented 4 years ago

Since it looks like we might be going the VirtIO route, be aware that there is a VirtIO randomness device supported by Linux, FreeBSD, Qemu, etc:

(This page last updated in 2015, but it appears that drivers, implementations, etc., abound. I’ve not dug in at all, so it could well be that there are no current hardware implementations snagging randomness from the host and spitting it into the FPGA environment via VirtIO .. or it could be there are.)

kiniry commented 4 years ago

See #71 and #72.

kiniry commented 4 years ago

UMich just pointed out that they need a good source of randomness for their P1+FreeRTOS. This was not on our radar previously. We are chatting via email about the options:

  1. VirtIO random device added to FireSim P1 config.
  2. a hardware RNG based upon a ring oscillator or similar (I pointed out that we tried this approach briefly in the past and did not succeed in getting a quality source of randomness), or
  3. a hardware PRNG based upon AES, which we do have in-hand and could give to UMich.

CC @toddmaustin @austinharris @taru-verma

dhand-galois commented 4 years ago

I'd add a 4th option:

  1. A host-based RNG, similar to VirtIO, but compatible with a simpler, existing Linux driver.

I can make a HWRNG device compatible with this ST driver relatively easily and quickly. It will pipe random numbers from the host machine to the target FPGA in 32-bit chunks. This is similar to how VirtIO works, but saves the time of re-implementing a VirtIO host/target interface in FireSim.

On P1s, you'd just have to add some code in FreeRTOS to poll the status register to check a random number is available followed by reading the designated memory location to get the number. On Linux, the ST driver will automatically add it as a randomness source by detecting it in the device tree.

rod-chapman commented 4 years ago

How many bits-per-second of randomness do Michigan need to drive their churning engine? That may well drive what technology will work for them.

rod-chapman commented 4 years ago

In case you're wondering what it does, see the "Morpheus" paper from ASPLOS 2019... https://dl.acm.org/doi/10.1145/3297858.3304037

toddmaustin commented 4 years ago

Thanks. We are seeking a true RNG source that can seed a PRNG.

AWS F1 won't allow bitstreams to have a ring oscillator (post build fails), that's where we got stuck building our desired TRNG source.

I like Dylan's approach, but just feed the Xeon RDRAND values into an LFSR on the F1 logic. (This might be Joe's option #1?) Seed it every few minutes, or even once per program load and I think we are good to go for FETT.

Best regards, -Todd

On Mon, Jun 15, 2020, 11:05 PM Joseph Kiniry notifications@github.com wrote:

UMich just pointed out that they need a good source of randomness for their P1+FreeRTOS. This was not on our radar previously. We are chatting via email about the options:

  1. VirtIO random device added to FireSim P1 config.
  2. a hardware RNG based upon a ring oscillator or similar (I pointed out that we tried this approach briefly in the past and did not succeed in getting a quality source of randomness), or
  3. a hardware PRNG based upon AES, which we do have in-hand and could give to UMich.

CC @toddmaustin https://github.com/toddmaustin @austinharris https://github.com/austinharris @taru-verma https://github.com/taru-verma

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DARPA-SSITH-Demonstrators/BESSPIN-CloudGFE/issues/34#issuecomment-644388998, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI2EERCDVN3UTVWXGYP52B3RW2EIDANCNFSM4MOJISBQ .

kiniry commented 4 years ago

It looks like this is ready for UMich to take for a test spin, and they have been notified in other channels.