Infinite Noise TRNG

1. Get the key fingerprints
The fingerprints of the code signing key used for all the packages and repositories can currently be found in four different locations:

• Crowd Supply campaign
• GitHub
• 13-37.org
• the user manual (link below)

After you did this, continue with the installation as described on Linux packages for the Infinite Noise TRNG

2. Download and verify the public key

$ wget -O 13-37.org-code.asc https://13-37.org/files/pubkey.gpg 

Verify the keys fingerprint:

# GPG1
$ gpg --with-fingerprints 13-37.org-code.asc
# GPG2:
$ gpg2 --import-options import-show --dry-run --import < 13-37.org-code.asc

3.1 Debian/Ubuntu

Add the public key to apt’s keyring:

$ sudo apt-key add 13-37.org-code.gpg

3.2 RPM

Import the public key to rpm’s keyring:

$ rpm --import 13-37.org-code.asc

3.3 ArchLinux

TODO

To compile the driver, you’ll need the libftdi development files installed. Usually called libftdi-dev – or also compile it from source.

$ git clone https://github.com/13-37-org/infnoise/
$ cd infnoise/software
$ make -f Makefile.linux
$ make install

The udev rule in software/init_scripts may not be installed properly this way. See the software’s README on github fore more details.

Each instance of the driver uses the corresponding USB device exclusively, so its not possible to run the driver twice – and trying to do so will result in these error messages.

Make sure you have stopped the Infinite Noise service, as it will try to restart – causing that error. If you’re using it behind an USB hub, try connecting it directly to your port. (Or try another USB port)

# sudo service infnoise.service stop

Optionally, you can also mask the service so it also won’t be restarted if you plug in the device.

# sudo systemctl mask infnoise.service

If all this doesn’t help, please contact us as this may indicate a problem with the hardware.

Yes – we can! But only on Linux (so far).

There are different scenarios in which this may be useful, as you can have only one session per device.

1. You want to use it in /dev/random mode and use the binary to play with random data at the same time

You could stop the service with service infnoise stop so you can execute infnoise without problems. Otherwise systemd will kick you out again (and you’ll se the error message USB read/write failed) as it tries to restart the driver.

The supplied systemd unit file reads a configuration file in /etc/infnoise.conf where you can INFNOISE_SERIALaccording to the device to be used for /dev/random mode – and use further devices for whatever you want.

If you don’t want it to start at all – just disable it with systemctl mask infnoise.

2. You need more speed

When you have a custom application requiring huge amounts of random data, you can attach at least 10 devices in parallel – as I do for production testing (at a single USB hub!).

Just be aware this may cause a lot of cpu load – especially when you want to combine it a huge whitening multiplier – and you’ll need to merge the data streams somehow (or use one device per thread?).

Note: Don’t use other devices on the same USB hub – and even better use a real port for each device, as timing issues may arise.

Just let it feed /dev/random and feel a bit safer while accelerating your cryptographic operations when you do lots of them.

This is the default mode of operation of the downloadable packages as feeding the kernel’s entropy pool is the simplest way to get entropy to where its needed.

The systemd service used to start the driver  configuration file /etc/infnoise.conf where you can change some parameters used in this mode of operation.

Note: Remember to stop the service before using the other ways described below.

$ sudo service infnoise stop

When you don’t want it to start when you plugin the device, you can disable it permanently with:

$ sudo systemctl mask infnoise.service

Execute the binary and capture its stdout for further processing (Windows, MacOS and GNU/Linux)

You can simply run the infnoise command with its various parameters command after compiling it from source or installing the compiled and signed packages.

Keep in mind you need to stop other instances running on the same device.

Call the binary within your custom application and capture stdout and optionally also stderr to use the data while monitoring the health monitor.

There are some usage examples for this on GitHub.

There is also a shared C library (libinfnoise) to built upon. Examples are also on Github (see above).

The Infinite Noise does not have microcontroller capable of this. It uses an off-the-shelf usb chip to interface with your computer. This way there is no programmable logic in the signal path. See update #3 for details.

Why this is an essential security feature? As the driver always sees the raw stream from the device, it is able to constantly verify the data is OK to use.

By using an off-the-shelf usb chip there is no reprogrammable logic in the signal path. This is great as it reduces the attack vectors on the device dramatically.

See updates #3 and #5 of the Crowd Supply campaign for more details.

The USB chip has no re-programmable logic, but still offers us access to an EEPROM to save application or USB specific data like the Vendor- and Product-ID’s as well as an usually factory programmed serial number (i.e. DM00WOEF)

In the first place, I did not want to change the EEPROM settings at all and just use the “unique” serial numbers from FTDI. But as we’ve been getting close to the 5000$ goal so fast, I continued working on the workflow to create the labels.

It turned out to be very complicated to read-out the actual serial number and print (super-small) labels one by one. And I wasn’t so sure about the uniqueness of FTDI’s serial numbers. That’s why a new serial number is assigned from a database of pre-generated ones right after the final production test has passed. The dataset of the specific serial number is completed with the test results, a batch number, the “unique” FTDI serial and a timestamp.

By integrating this into the automated workflow of device testing I just need to put the right label onto the device (and my script tells me which one goes where).

Yes you can! Using the FTDI FT_Prog utility for Windows this is pretty easy. There is also a command line tool ftdi_eeprom included in the fully open-source FTDI driver that I’m using in the production workflow – buts its very low-level.

Using the online verification service you can download a generated config file to restore it’s original or its production serial, using the .CONF for the Linux tool or .XML for Windows/FT_Prog.

If you have removed the security label (or did not have one), write down your original serial number before you continue, otherwise you might lose it forever. There is no way for me to associate the serial numbers to purchases, so I won’t be able to help you. Warranty claims are of course still possible, as long as you have the invoice/order receipt.

Of course you can access the raw output stream by using --raw – but has only 286.000 bits of entropy in 300.000 bits. Anyway its a very reliable source of true random numbers to feed into a hashing function (like SHA-3). If you want to feed it into a different whitening algorithm – using --raw is an option. When going this way its probably easier to integrate it in the existing open source driver (and share).

Normally the driver reads as many bytes from the Keccak sponge as raw data was put in. As we read the full buffer of the USB chip at once, this is always 64 bytes/512 bits of entropy per round.

Using the multiplier the data rate be extended to 256 * MULTIPLIER bits with (almost) no degradation in entropy.
Data is still read in chunks of 1024 bits between each permutation of the Keccak state, to not compromise the full internal state (which has 1600bit/200 bytes). After 256*MULTIPLIER bits have been read, it is reseeded with 512 bits of raw entropy. The full Keccak state is never exposed, as this would allow attacks on it.