close-circle
Close
0%
0%

Orthrus

SD card secure RAID USB storage

Similar projects worth following
close
This project is a hardware mechanism to provide secure "two man control" over a data store. It is a USB microSD card reader, but it requires two cards. The data is striped in the style of RAID 0, but the data is also encrypted with a key that is stored in a key storage block on each card. In essence, each card is useless without the other. With possession of both cards, the data is available without restriction, but with only one, the remaining data is completely opaque.

This allows you to securely transport a data set by writing it onto a pair of cards and separately transporting them to a destination for recombination.

The intent is that only the pairing of two cards becomes in any way special. A card pair could be inserted in any Orthrus device and the data would be made available. But with only one card, all you get is half of the data encrypted with a key which you only half-possess.

I'd like to express my gratitude to Dean Camera of the LUFA project.

Orthrus dramatically simplifies the problems of providing a securely encrypted data store. There are no passwords or key material to manage. The act of pairing two cards together automatically creates all of the key material necessary to secure the store without any human action (other than initiating the paring process by pressing and holding a single button). The security offered by Orthrus is simple to explain and trivial to use. It's simply that if you have both of the cards, you have the data. If you have only one of them, then it is cryptographically opaque.

The first block of each card is reserved as a key storage block. The size of the volume reported to the USB host is determined by taking the smaller of the two card sizes, subtracting one and doubling that. The first block on each card contains a structure with the following:

  • A magic constant compiled into the firmware to identify the card as belonging to an Orthrus volume.
  • A flag bit identifying the card as either the "A" or "B" card (the cards can be inserted in either order and it should still work).
  • A 32 byte volume ID.
  • A 32 byte card key value.
  • A 16 byte nonce value for the block tweaking (of which 12 bytes are used).

When the device is initialized (either when its inserted into a host with two cards already installed or when the second card is inserted), each of the key blocks is checked. If the magic value is wrong, or if the two volume ID values don't match or if there isn't one "A" and one "B" card, then the error light is turned on and the volume isn't mounted. This prevents cards inserted mistakenly from being corrupted. To bootstrap, there's a button on the board. If the button is pushed while the error light is on, then the two key blocks are initialized and the device made ready.

If the pre-initialization checks succeed, then the two card key values are concatenated (in "A" "B" order) to make a 64 byte buffer. This is fed through AES CMAC with an all-zero key. The result of that becomes the new AES key and the CMAC is run over the volume ID. This two-step operation is also known as AES-CMAC-PRF. The result of that becomes the AES key for the volume. At that point, the drive is ready.

To read and write individual blocks, AES XEX mode is used. The incoming block number in the request is translated by using the LSB to select either the "A" or "B" card. The rest of the block number is right-shifted once and 1 is added to make the physical block number for the card. The XEX mode uses a 16 byte nonce. The nonce consists of the first 12 bytes of the nonce value stored on the opposite card from the one being read or written, concatenated with the (logical) block number. The nonce is encrypted with the volume key to form the first "tweak" block. For each 16 byte AES block of the disk sector, the plaintext is XORed with the tweak block, then encrypted with AES ECB mode, then XORed again with the tweak block to form the ciphertext. Decryption is the same, except that an AES ECB decryption operation is performed in the middle (the tweak is still formed with an ECB encryption). After each block is processed, the tweak block is transformed into a new tweak block by multiplying it by 2 within a Galois Field of 2^128 (I confess I don't really understand GF math properly - I just read a bunch of examples and pseudocode on the net) and then is ready for the next 16 byte block.

In an earlier iteration of Orthrus, AES counter mode was used, which allowed us to precompute the cipher stream bytes for XORing with the card data, but counter mode has some cryptographic weaknesses that make up for the speed advantage that background precomputation affords. XEX mode can't be precomputed, and unfortunately gives us a 33% speed penalty, but is the mode used almost universally for whole-disk encryption (most implementations actually use XTS, but if the sector size is divisible by the encryption block size, then the two are the same).

To initialize a card, 8 16-byte blocks worth of data...

Read more »

codesign.x509

Code signing certificate

x509 - 644.00 bytes - 10/09/2017 at 18:39

download-circle
Download

Orthrus-firmware.zip

Release firmware with signature

Zip Archive - 15.78 kB - 10/15/2017 at 20:00

download-circle
Download

Orthrus_3_0_1.pdf

v3.0.1 schematic as a PDF

application/pdf - 99.56 kB - 10/09/2017 at 01:23

eye
Preview
download-circle
Download

Orthrus_3_0_1.sch

v3.0.1 EAGLE schematic file

sch - 361.21 kB - 10/09/2017 at 01:23

blank
See BOM
download-circle
Download

Orthrus_3_0_1.brd

v3.0.1 EAGLE board file

brd - 159.62 kB - 10/09/2017 at 01:23

download-circle
Download

View all 12 files

  • 1 × ATSAMS70N19 LQFP-100 ARM microcontroller Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 2 × QS3VH257PAG Logic ICs / Buffers, Drivers, Transceivers
  • 1 × 5.62kΩ 1% 0805 resistor
  • 5 × 100kΩ 0805 resistor
  • 1 × PAM2305 3.3v buck regulator Power Management ICs / Switching Regulators and Controllers

View all 28 components

  • More firmware improvements

    Nick Sayera day ago 0 comments

    I've figured out how to make use of the tightly coupled memory (TCM) on the SAMS70. The TCM comes in two chunks - ITCM for code and DTCM for data. Configuring TCM results in a reduction in the amount of SRAM available. I've compromised and configured 64K each of ITCM and DTCM, which results in 128K of SRAM.

    I'm using the ITCM for some of the hot-spot code centered around the cryptography. That makes a little less impact, however, due to the fact that I previously was able to enable the ICache (enabling the DCache isn't quite so easy, as you have to sprinkle cache invalidation calls throughout your code to get away with it). I've moved the stack, the main disk block buffer and a few other crypto-related data structures into DTCM. I tried to move everything there, but that hasn't worked. Still, even with just that much (and with -O3), the throughput for sequential reads is North of 1.3 MB/sec.

    I've also managed to extract the chip's unique ID and turned that into a USB serial string. It shouldn't really matter, but you can use that to tell two Orthrus' apart (or make sure that your Orthrus hasn't had its controller swapped out without being noticed).

  • Secure case progress

    Nick Sayer4 days ago 0 comments

    My friends at SteamyTech are going to be designing and making the cases for Orthrus. The first prototype wasn't perfect because the board and its components were thicker than the acrylic used to make the layers. The result of that was that two layers would have been required between the top and bottom. I've ordered new PCBs with 0.8mm thickness instead of 1.6mm, and with that the height of the board and its components (except the button) should fit in 1/8". I'm sourcing some 1/16" acrylic rods from Amazon to hold a piece in place between the two SD card slots. Lastly, I'm going to see if Olander has some 4-40 threaded flanged inserts that can be used instead of bolts.

    I've gotten some samples of security seals. Recall that the entire point of putting Orthrus in a case is to keep adversaries away from the ERASE header (make no mistake - even if I didn't populate an ERASE header, the chip still has the pin, and it's well documented). With Orthrus in its case, as long as you know that no one has opened it, and if the firmware was programmed with the security bit on, the chances are quite slim that anyone would be able to install rogue firmware.  The seals I've chosen are FIPS 140-2 certified holographic serialized seals. As long as you keep a record of the serial numbers sealing your Orthrus and see that they don't change without your knowledge, you should be able to trust the firmware. To insure that the firmware isn't tampered with in transit, orders for Orthrus that include the case will have the serial numbers on the seals communicated separately so that the buyer can confirm they haven't changed in the mail.

    There are some small gaps that could conceivably be used to fish a small wire into the case, but I think it would require Mission: Impossible levels of effort to be able to successfully access the ERASE header without breaking a case seal.

    I will be selling replacement seals in pairs for a nominal charge on the Tindie store to facilitate re-sealing Orthrus after field firmware updates.

    This is about as secure a system as I can design. If anyone has suggestions for things I've missed that can improve things, I'd love to hear about them.

  • Firmware signing

    Nick Sayer10/09/2017 at 18:43 0 comments

    In order to further protect against rogue firmware, I've created a firmware signing certificate and used it to sign the firmware in the release zip. There's also a README included with the steps to validate the signature. It's simple operations with OpenSSL. The code signing certificate is also separately included in the Files section of the project and has been checked into GitHub, but if you're really paranoid then you should contact me offline somehow and I can provide you with the expected SHA256 hash of the certificate or some other reasonable proof of authenticity.

    If it turns out there is some reasonable and free mechanism for obtaining a trusted code signing certificate, I'll endeavor to resign the same public key, if possible.

    Meanwhile, this will allow for reasonable security around field firmware updates.

  • Firmware complete

    Nick Sayer10/09/2017 at 16:13 0 comments

    The first version of the firmware is now really complete. There were a couple of bugs discovered since the last time I said that:

    • all calls to msc_xfer_blocks() results in a callback to the xfer_done() method, including the call after a write with block count 0 to mark the write commit.
    • In Atmel Start's world, you're not allowed to have side effects in ASSERT(), as it is optimized to a null statement in release builds. So "ASSERT(NO_ERROR == perform_action());" doesn't call perform_action() in release builds. You have to assign the result to a variable and ASSERT the variable value instead.

    With that, the raw block read speed of Orthrus is something like 1.25 MB/sec and the write speed is just over 300 kB/sec. So the goal was achieved. But there's hope that with a little bit more work to turn on the DCache and perhaps even move to TCM that this might improve even more. We'll see.

  • UVLO for better security

    Nick Sayer10/07/2017 at 01:12 0 comments

    As previously discussed, for maximum security, the goal will be to encase the Orthrus board in a tamper-evident sealed case to keep miscreants away from the ERASE pins. The idea is that as long as the case remains sealed (and the seals are serialized, so you can be sure they haven't been replaced), you have some level of trust that the firmware hasn't been tampered with.

    This means that there are four things open to an attacker to monkey around with: the button, the two SD card slots and the USB connection.

    The button, SD card slots and the USB data bus all fall under the purview of the firmware, so it's on me to make sure that there aren't any bugs there. I make no sacrosanct promises, but I'm going to do my best to squish anything I find, either in my code or ASF4.

    What's left is the power supply. Since it's potentially under the control of an attacker, that makes the system potentially vulnerable to power games.

    Make the voltage too high and you'll likely destroy something. That isn't really a security vulnerability, per se.

    But when the voltage of a microcontroller goes too low, stuff starts to just go wonky in ways that are unpredictable. It's a crude attack, but it's been shown in the past to bear fruit.

    The defense is an UVLO circuit. If the voltage on the (nominally) 3.3 volt bus drops lower than 3 volts, the supervisor will pull the NRST line to ground, which will hold the chip in reset. If the voltage goes above the threshold, it holds the chip in reset for an extra 20 ms before releasing it.

    The MIC803 is just the ticket. It's output is an open-drain, so it won't interfere with NRST being driven by the JTAG/SWD port, and there's already a 100 kΩ pull-up on that line.

    This will be added to the next set of boards built, but it won't be on the first boards that ship (or the boards for the HP judges).

  • Incremental improvements

    Nick Sayer10/05/2017 at 16:21 0 comments

    Turning on the ICache brings performance up to around 875 KB/sec. Unfortunately, turning on either DCache or ITCM causes USB to break. Probably cache coherency issues or something like that. I'll look into it. TCM would likely be a huge boost for the system if it could be made to work.

  • First firmware release

    Nick Sayer10/04/2017 at 23:17 0 comments

    The firmware is now feature-complete and ready for use. I've uploaded a release build of the firmware. You can build your own hardware and use micro-samba to load it as described in an earlier log.

    This firmware build assumes a 12 MHz crystal. I'll be using those exclusively going forward, as they allow maxing out the CPU frequency. That said, 16 MHz will also work if that's what you've got handy. Be sure to adjust the .atstart accordingly.

    The release build running at 300 MHz benchmarks at around 750 kB/sec. Short of the goal, but close, and much better than v2.

  • Firmware success

    Nick Sayer10/04/2017 at 14:22 0 comments

    I got Orthrus v3 hardware working all the way as a disk drive last night. There are a few bugs in Start's code that you have to work around:

    • Start doesn't adjust the UTMI_CKTRIM register when configured with a 16 MHx crystal. You have to do that yourself.
    • mscdf.c has no support for the MODE_SENSE_6 command, which is necessary (you just have to give back 4 zero bytes).
    • mscdf.c has a bug where it returns non-zero when there's no error sending the zero-length "sync" at the end of a write.
    • Start doesn't allow you to configure 512 byte endpoints, as the HS spec requires.

    There are still a couple of bugs to work out - mostly centered around the handling of situations where cards are removed or missing.

    Performance is not as good as hoped. Throughput is around 540 MB/sec. Halving the SD card clock doesn't appreciably change throughput, so this may be being limited by USB. But even at only ~5 times faster than before, it's now actually usable as opposed to unacceptable.

    Another couple of days to polish the firmware, and I think I'll be able to send some units off to the HP judges!

  • More progress

    Nick Sayer10/04/2017 at 04:15 0 comments

    We're now at the point where USB attempts to start doing block I/O, but that's not working.

    I've checked in my progress so far. To use it, grab the .atstart and open it in Atmel Start. Save the result as an Atmel Studio 7 project, then open it in Atmel Studio.

    Next, add the bizarro workaround to the start of ResetHandler() in the startup code.

    Now you have to change the CONF_USB_MSC_BULKIN_MAXPKSZ and CONF_USB_MSC_BULKOUT_MAXPKSZ constants from 0x40 to 0x200. They're located in usb_msc_config.h under Config.

    Lastly, copy the .c and .h files into your project, overwriting any that may have been put there by Atmel Start. Don't forget to add them all to the project.

    Rebuild the project and you're good to go.

    If anyone can figure out what I'm doing wrong with the I/O transfer code, let me know.

  • Getting closer

    Nick Sayer10/03/2017 at 05:06 0 comments

    It turns out that if you swap out the 16 MHz crystal for a 12 MHz one, USB seems to work a lot better. The firmware hasn't completed the full attach sequence just yet, but it's much further along.

    It's unclear why 16 MHz doesn't work. The datasheet says both are acceptable, and both work with SAM-BA in ROM. But Atmel Start doesn't have any knob I can find that you need to flip for the UPLLCK when it's coming from a 16 MHz source, and there's nothing in the datasheet about that either.

    12 MHz is arguably a better choice anyway, since it's 300 divided by 25, which means that the CPU clock speed can be maxed out (I was using 288 MHz before).

    Another bug in Atmel Start is that it won't allow you to set a bulk endpoint maximum packet length of higher than 64. The hardware supports up to 1024, and the high-speed spec requires a minimum of 512 (alas, that change isn't enough to fix the enumeration problems).

    So... that's progress, at least.

    I've updated the schematic / board files, making v3.0.1. The 3.0 boards are still fine - nothing much changed on the board. I've added a 0 Ω resistor as a disconnect point for Vddcore so you can experimentally disconnect it if you're so inclined (the resistor pads have a trace jumping them so there's no need for an actual part). There'a also an ever-so-slight tweak to the USB line layouts, but it's not so significant as to make much of a difference (beyond being more theoretically correct). High speed differential signals like that should not have "T" paths, and I made a small pair to connect the TVS protection diode matrix. Now the traces enter and exit the pads, meaning they stay more linear.

    Version 3.0 is still what's going to be submitted to the judges for the HP. I just need to get USB working the rest of the way...

View all 54 project logs

  • 1
    Using Orthrus

    To use Orthrus, just stick any two SDHC or SDXC microSD cards in the slots and connect a USB cable to your host. You can do this in the opposite order if you wish - the microSD slots are hot-swappable. If the two cards have not been previously paired with Orthrus, then the error light will turn on. Press and hold the button and the error light will blink for 5 seconds and then the cards will be paired and initialized. At that point the ready light will turn on and the host will see a volume with twice the space of the smaller of the two cards. You will need to use your host to initialize this volume. After that, it works just like any other USB storage. When ejecting the volume, you can either remove the USB cable or the two cards first.

    If you insert an Orthrus paired card into a computer (that is, without Orthrus), it will look like a card filled with garbage. If you damage the key block (block 0 on the card), then THE ENTIRE VOLUME ON BOTH CARDS WILL BE DESTROYED. Once the key material is corrupted, then all the data is irrecoverably lost. That's kinda the point, of course.

    There are three lights on Orthrus - ready, activity and error. "Ready" indicates that a correctly matched pair of cards have been inserted and the volume is available to the host. "Error" means that the two cards that are inserted are not a matched pair. You can press the button to pair two such cards, but that will destroy any data on both of them. You can hold the button down for 5 seconds (the error light will blink while you do this) at any time and the two cards will be initialized. If you do this while two paired cards are inserted then all the data on the volume will be destroyed and the volume made ready for new data.

    It does not matter which card of a pair is inserted into each slot. The two slots are marked on the board, but in use they are fungible.

  • 2
    Hardware build

    There are no particularly noteworthy steps for building the hardware - it's normal surface-mount assembly. For most users, there is no need to populate the two through-hole connectors. You can just short ERASE with a wire briefly when it's necessary, and the SWD interface is not used except for firmware development.

  • 3
    Firmware build

    To build the firmware, use Atmel Studio 7 and Atmel Start. This will make an ASF4 codebase from the .atstart file in the GitHub repository. Download the .atzip from Start and open it in Atmel Studio. You need to patch the result in a couple of specific ways:

    • There is a patch to the ResetHandler() that's necessary to handle cases where the GPNVM bits are incorrect. You can skip this if you use SAM-BA to set the bits properly, but if you're using Atmel Studio, there is a bug that makes it impossible to do this correctly.
    • You need to manually change the two bulk endpoint maximum sizes (CONF_USB_MSC_BULKIN_MAXPKSZ and CONF_USB_MSC_BULKOUT_MAXPKSZ in Config/usbd_msc_config.h) from 0x40 to 0x200 as the HS USB spec requires (and for better performance).

    After doing that, take all of the .c and .h files in the GitHub repository and overlay them on top of the project, overwriting any conflicting existing files.

    Select a "Release" build (for better performance) and compile the code. Find the ".bin" file in the Release directory. This is what you'll upload to the controller.

    Fetch and compile the source for the Micro-SAM-BA client.

    Short the ERASE jumper on the board and apply power, then remove the short. You will see a CDC (serial port) device show up on your host. Take note of the device name (the file in /dev that it added). Use the following usamba commands:

    usamba [device] write Orthrus.bin
    usamba [device] gpnvm set 1
    usamba [device] gpnvm set 8
    usamba [device] gpnvm clear 7
    export GPNVM0_CONFIRM=1
    usamba [device] gpnvm set 0

    That last two commands will set the security bit and "lock" the firmware in and disable all debug interfaces. This will protect you from rogue firmware being installed as long as you prevent access to the ERASE jumper. Unplug the USB cable to terminate SAM-BA and connect it again to start the new firmware.

View all 3 instructions

Enjoy this project?

Share

Discussions

CJ wrote 09/10/2017 at 18:41 point

Took a look at the new version of the schematic, overall it looks great. Some obvious big improvements (simplifications, really) compared to the previous AVR-based design. Getting rid of all that hardware RNG is a big win. This new design definitely seems much more by-the-book, which is rarely a bad thing. Some more specific comments:

- Looks like the LEDs, buttons, high-side card power switch, SD card slots, and 3.3V buck are all holdovers from Rev 2. So all that stuff should be proven already, nice.

- USB looks mostly the same, but with the ESD consolidated. Checked that, looks good.

- The bus-mux looks good. Takes a minute to understand IC2 and IC3 are essentially one "thing" doing one job but it's simple once you understand. It looks like the mux chips may be both missing their bypass caps?

- Right now you've got a single signal "/CRDEN" applying power to the SD cards *and* enabling the output drivers on your data mux. That's clever and likely fine, but considering you have crazy IO left over, consider separating those into two control signals. CRDEN_PWR and CRDEN_DATA or something. There may turn out to be some benefit to being able to sequence those slightly (power first, wait a beat, then data?) and even if there is no benefit, this change costs nothing in dollars or performance. Put them on the same logical port for the ARM and they can switch simultaneously.

- I would also consider adding a discrete pullup (1kΩ - 10kΩ) to the CRDEN signal(s) to guarantee that those parts stay hella off (esp during power-on) until the ARM explicitly turns them on. 

- Considering the short distances covered by these traces, and the likely good slewrate control (etc) offered by the ARM, I doubt signal integrity vis-a-vis rise times, reflections is going to be an issue at all. BUT if you haven't done at least a very basic estimate of this it's probably good to do it, just to prove to yourself. It may turn out to be smart to add source termination resistors to the ARM, the mux, or both.

- I said no nits, but here's a little one anyway. R12-R14 are the only discrete 100kΩ resistors in the design. If the array part you use for R19 is cheap, consider using it again instead of those discretes. Might be worth it to drop a line from your BOM and get rid of a couple placements. If you can add the CRDEN pull-ups (recommended above) to the second array, it'd be almost half full. Not bad.

  Are you sure? yes | no

Nick Sayer wrote 09/10/2017 at 18:53 point

Thank you so much for going over the design. I'm going to definitely take some of your advice. I'd like to get one more round of conversation, if you don't mind, about some of your points:

- The bypass caps for the two bus mux chips are there - they're C7 and C8.

- Separating the power and logic enable for the card bus is also not a bad idea, and you're right - I do have crazy GPIOs left over. The same could be done in software, in principle, by making those pins into inputs when the power is off, but an "input" isn't the same as "disconnected," certainly.

- pull-ups for the card power and enable are *definitely* a good idea. Thanks for mentioning that.

- The only reason I don't think reusing R19 is good is that it's *huge*. The R19 part in the schematic has a couple of resistors left over, but unfortunately, they're powered from the switched card power, so they can't be used as pull-ups elsewhere. Those pull-ups can't be powered straight from 3.3v, because of the possibility of power leakage via the logic lines preventing the cards from being truly powered off (though a 100k impedance may make that point moot). With the card power / enable pull-ups being added, there are now 5 discrete pull-ups, but placing them in a common location to use an array may be more trouble than it's worth.

  Are you sure? yes | no

matt venn wrote 05/09/2017 at 08:58 point

Hey Nick,

thanks a lot for posting this - I learnt a lot over my morning coffee! You made it very easy to browse - even a pdf schematic, nice.

  Are you sure? yes | no

Nick Sayer wrote 05/09/2017 at 13:34 point

You're quite welcome, and thanks for saying so! For security related projects, I feel like it's really important to shine a bight light onto every aspect so it's obvious that nothing is hiding behind a curtain. Inviting scrutiny is the only way you can have any confidence that you got it right.

  Are you sure? yes | no

tz wrote 05/08/2017 at 21:12 point

Depending on configuration, you might find my SPI transfer faster

https://github.com/tz1/sparkfun/blob/master/fat32lib/sdhc.c

I also have write protect and password protect routines, and the whole is a minimal FAT32 implementation, originally for Sparkfun's OpenLog.

  Are you sure? yes | no

Nick Sayer wrote 05/08/2017 at 23:13 point

Thanks for that! I'll definitely take a look. I bought an OpenLog a while ago to capture logs from my GPSDOs. I don't need filesystem support for Orthrus, but I'll take any opportunity to see if there are better ways to get the block I/O done.

  Are you sure? yes | no

Nick Sayer wrote 05/09/2017 at 00:51 point

The big difference I see is that you've been very clever about timing your writes to SPDR to eliminate the dead time caused by the read-and-test-branch busy-wait operation. I thought I could achieve something similar by using the ATXmega USART-in-SPI-master mode functionality - the transmit register is double-buffered, which in principle means that you can always have a byte going out. At least for my first experiments that didn't work out so well, but I am contemplating giving that another go at some point.

  Are you sure? yes | no

Clayton G. Hobbs wrote 04/29/2017 at 00:25 point

Very interesting idea!  Couldn't the whole thing be done in software though, using two normal SD card read/writers, and with faster data transfer speeds than are possible with Full Speed USB?

  Are you sure? yes | no

Nick Sayer wrote 04/29/2017 at 00:57 point

Very likely. This does, however, turn the whole concept into an appliance that's very easy to use. You could write a FUSE module to do an interoperable version of this for Linux, certainly.

  Are you sure? yes | no

Martin wrote 04/14/2017 at 08:50 point

Be careful with your entropy generator. When you want to use noise as a RNG you have to keep noise out :-) That means any non thermal, non random noise. So you have to use good decoupling and shielding for your noise generator. Otherwise there could be some interference from power line hum or your local (AM) radio station which compromises your randomness and thus your security, because it ads a deterministic element.

If  the Atmel is too weak perhaps the recently discussed STM32F103 could be a solution.

  Are you sure? yes | no

Nick Sayer wrote 04/14/2017 at 13:40 point

I plan on gathering a goodly chunk of the entropy from the generator and running it through DieHarder to insure that it's of good quality, plus it's going to be run through AES to whiten it before it's actually used. This design is well worn. It's the basis for several open hardware entropy source peripherals out there, so I am fairly confident.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates