Operation
Each of the two random noise sources of the TL200 are analog electronic circuits that generate random electronic signals from reverse-biased Zener diodes. The electrical noise generated by each random source is independently amplified and converted using ADC into digital values as bytes.
The TL200 implements an embedded health check test (HCT) that continuously monitors the quality of the random noise sources immediately after the electrical noise is digitized and before any further processing takes place.
Two random bytes generated by noise sources are used to produce one low bias random byte by applying logical operations. To further reduce bias, the resulting byte stream is processed by a conditioning component with one of the keyed or un-keyed conditioning functions such as SHA160, SHA256, SHA512 and HMACSha160 approved by National Institute of Standards and Technology as described by NIST SP 800-90B DRAFT document section 6.4.2
The monitoring logic will check the quality of the final random bytes produced by continuously running ‘Repetition Count Test’ and ‘Adaptive Proportion Test’ tests. The embedded monitoring logic will put the device in ‘stop’ mode and will flash the LED light if it detects an unexpected deviation from normal operation or complete miss functioning of any of two random sources. This device is completely powered by a USB bus. It doesn’t require additional power source and it is protected by an overload protection circuit.
The TL200 PCB layout is designed to isolate and minimize the impact of the random electrical noise from the USB data and power lines. In addition to the FT232R circuit used for the USB interface, the device is equipped with ESD protection and Bi-directional EMI filtering circuit. After the TL200 is plugged into a USB host, it becomes ready to accept commands within 2-5 seconds (this time is used to run start-up tests and waiting for USB driver readiness). User can disable or enable certain start-up tests (see section ‘User Interactive Mode’).
The TL200 can operate in three modes: ‘True random bytes (default), ‘Low bias random bytes’ and ‘Raw random bytes’. See the table below for more details:
Mode | Download speed | Start-up tests | Continuous tests | Description |
---|---|---|---|---|
True random bytes – SHA256 | 2 Mbps* | ‘Health Check’, ‘Repetition Count’ and ‘Adaptive Proportion’ tests | ‘Health Check’, ‘Repetition Count’ and ‘Adaptive Proportion’ tests | This is the main and recommended generation mode. Random bytes generated in this mode will pass statistical tests Diehard, Dieharder, NIST, and ENT. In this mode, SHA256 processing is provided by host computer to achieve higher download speed. |
Raw random bytes | 2 Mbps* | ‘Health Check’ test | ‘Health Check’ test | This mode is for generating raw (unprocessed) random bytes. Bytes generated in this mode are not expected to pass any statistical tests. It can be used in situations when there is a need to apply different post processing logic to remove bias when generating random bytes. |
Low bias random bytes | 2 Mbps* | ‘Health Check’, ‘Repetition Count’ and ‘Adaptive Proportion’ tests | ‘Health Check’ test | This mode is for generating low bias random bytes. Bytes generated in this mode will pass most of the known statistical tests. It is to be used with different whitening or bias remover algorithms or with host computer post processing. |
True random bytes – SHA160 | 830 Kbps | ‘Health Check’, ‘Repetition Count’ – DISABLED by default, ‘Adaptive Proportion’ – DISABLED by default | ‘Health Check’, ‘Repetition Count’ and ‘Adaptive Proportion’ tests | Random bytes generated in this mode will pass known statistical tests |
True random bytes – SHA512 | 872 Kbps | ‘Health Check’, ‘Repetition Count’ – DISABLED by default, ‘Adaptive Proportion’ – DISABLED by default | ‘Health Check’, ‘Repetition Count’ and ‘Adaptive Proportion’ tests | Random bytes generated in this mode will pass known statistical tests |
True random bytes – HmacSha160 | 432 Kbs | ‘Health Check’, ‘Repetition Count’ – DISABLED by default, ‘Adaptive Proportion’ – DISABLED by default | ‘Health Check’, ‘Repetition Count’ and ‘Adaptive Proportion’ tests | Random bytes generated in this mode will pass statistical tests. The unique random key used for the HmacSha160 algorithm is generated by the device when first plugged into the USB host. |
* The actual download speed may vary based on the selected device power profile, host OS and computing hardware (2.0 Mbps download speed or faster can be achieved on a host computer using I5 or faster CPU when device power profile 5 is selected)
Supported systems
- Windows XP /Server / Vista / 7 / 8 (32 or 64 bit) / 8.1 — The OS will automatically install an FTDI third party USB Windows certified driver once the TL200 device is plugged into a USB port. The GetRND software utility is shipped as a ‘Microsoft Visual C++ 2010 Express’ 32 bit console project, ready to be built on a Windows platform. The project also contains all necessary API source code and FTDI third party files that can be included in other projects for communicating with the TL200 device.
- macOS — The kernel already contains the FTDI USB driver. The GetRND software utility is shipped as a ‘Make’ project, ready to be built. The project also contains all necessary API source code and FTDI third party files that can be included in other project for communicating with TL200 device. The project requires ‘Make’, ‘gcc’ and ‘C++’ components to be installed prior to building the project.
- Linux (x86, x64) — The kernel already contains the FTDI USB driver. The GetRND software utility is shipped as two ‘Make’ projects (one for x68 and one for x64), ready to be built. The project also contains all necessary API source code and FTDI third party files that can be included in other project for communicating with the TL200 device. The project requires ‘Make’, ‘gcc’ and ‘C++’ components to be installed prior to building the project. Through the provided ‘tlrandom’ kernel module, the random bytes generated by the TL200 will be available for download from the device /dev/tlrandom on x86-64 systems such as Ubuntu, Cent OS 7, Cent OS 6.6 and other Linux based x86-64 systems.
Fabrication and testing
The TL200 device is designed and assembled in the United States. After each PCB is fabricated and assembled by an independent assembly house, both random noise sources are individually inspected and verified using an oscilloscope and a spectrum analyzer to test that the electrical noise characteristics are within expected ranges. The device does not require any tune-up after it is assembled. Before it is shipped, the output random bytes of each TL200 are tested by running well known statistical tests for randomness such as: Diehard, Dieharder, NIST, and ENT.
View the following files for statistical test reports:
- Diehard test reports: Generator 1, Generator 2
- Dieharder test reports for 280GB random binary files: Generator 1, Generator 2
- ENT test reports: Generator 1, Generator 2, Generator 3 (280 GB)
- STS NIST test reports: Generator 1, Generator 2
Embedded health check and monitoring
The TL200 device implements an embedded health check test (HCT) that continuously monitors the quality of the random noise sources immediately after the electrical noise is digitized and before any further processing. In addition to running ‘HCT’ test, the monitoring logic will check the quality of the final random bytes produced, by continuously running ‘Repetition Count Test’ and ‘Adaptive Proportion Test’ tests. The embedded monitoring logic will put the device in ‘stop’ mode and will flash the LED light if it detects an unexpected deviation from normal operation or complete miss functioning of any of the two random sources. In addition, the monitoring logic will append a ‘Health Status Byte’ to each random data response so that the caller is continuously notified about the health of the device.
TL200 device API
With the purchase of a TL200, a software kit is available here that contains the GetRND utility used for discovering TL200 devices attached to USB ports and for downloading random bytes. It also contains a software API and sample source code based on C/C++ that simplifies communication with the device and makes it easy to integrate with different projects. The device can also be accessed directly, bypassing software API by using TL200 device API. TL200 device API operates based on 1 byte, 2 byte or three bytes commands. The following table contains the complete command set and descriptions.
Command | Response | Description |
---|---|---|
x + 16 bit unsigned integer |
Requested amount of bytes + status byte | This 3 bytes command is used to retrieve low biased random bytes from the device. The 16 bit unsigned integer represents the requested amount of bytes (max value is 50000), the lower byte is sent first and then the higher byte is sent. The TL200 device expects to receive all three bytes within a reasonable amount of time. There should not be delays longer than 90 milliseconds between moments when sending each byte, otherwise the device will ignore the command. The response will contain low biased random bytes. This command can be used in a situation when the user needs to apply a different bias removing (whitening) logic for generating true random bytes. The last byte in the response is the status byte. |
1 + 16 bit unsigned integer |
Requested amount of bytes + status byte | This 3 bytes command is used to retrieve true random bytes from the device by hashing low bias random byte stream with SHA-160. The 16 bit unsigned integer represents the requested amount of bytes (max value is 50000), the lower byte is sent first and then the higher byte. The TL200 device expects to receive all three bytes within a reasonable amount of time. There should not be delays longer than 90 milliseconds between moments when sending each byte, otherwise the device will ignore the command. The last byte in the response is the status byte. |
2 + 16 bit unsigned integer |
Requested amount of bytes + status byte | This 3 bytes command is used to retrieve true random bytes from the device by hashing low bias random byte stream with SHA-256. This is the recommended mode for retrieving true random bytes. The 16 bit unsigned integer represents the requested amount of bytes (max value is 50000), the lower byte is sent first and then the higher byte. The TL200 device expects to receive all three bytes within a reasonable amount of time. There should not be delays longer than 90 milliseconds between moments when sending each byte, otherwise the device will ignore the command. The last byte in the response is the status byte. |
3 + 16 bit unsigned integer |
Requested amount of bytes + status byte | This 3 bytes command is used to retrieve true random bytes from the device by hashing low bias random byte stream with SHA-512. The 16 bit unsigned integer represents the requested amount of bytes (max value is 50000), the lower byte is sent first and then the higher byte. TheTL200 device expects to receive all three bytes within a reasonable amount of time. There should not be delays longer than 90 milliseconds between moments when sending each byte, otherwise the device will ignore the command. The last byte in the response is the status byte. |
h + 16 bit unsigned integer |
Requested amount of bytes + status byte | This 3 bytes command is used to retrieve true random bytes from the device with HmacSHA256 post processing. The 16 bit unsigned integer represents the requested amount of bytes (max value is 50000), the lower byte is sent first and then the higher byte. TL200 device expects to receive all three bytes within a reasonable amount of time. There should not be delays longer than 90 milliseconds between moments when sending each byte, otherwise the device will ignore the command. The last byte in the response is the status byte. |
v |
3 bytes + status byte | This 1 byte command is used to retrieve device version number in ASCII followed by the status byte. |
m |
6 bytes + status byte | This 1 byte command is used to retrieve device model in ASCII followed by the status byte. |
s |
30 bytes + status byte | This 1 byte command is used to retrieve the unique device serial number in ASCII followed by the status byte. |
u |
This 1 byte command is used to activate user interactive console mode. See User interactive mode section for details. After this command is issued, user will be prompted to provide a valid pass code within a limited amount of time. When successfully authenticated, user will enter interactive menu based mode. This command should be used with care since the device won’t handle any other commands when in this mode. User should follow the interactive menu and exit from this mode when done. |
|
r + 16 bit unsigned integer |
Requested amount of bytes + status byte | This 3 bytes command is used to retrieve raw (unprocessed) random bytes from the device. The 16 bit unsigned integer represents the requested amount of bytes (max value is 50000), the lower byte is sent first and then the higher byte. The TL200 device expects to receive all three bytes within a reasonable amount of time. There should not be delays longer than 90 milliseconds between moments when sending each byte, otherwise the device will ignore the command. The response will contain biased raw random bytes, the response bytes are not expected to pass statistical tests. This command can be used in a situation when the user needs to apply a different post processing logic to remove the bias for generating true random bytes. The last byte in the response is the status byte. |
p |
1 byte + status byte | This 1 byte command is used to retrieve the current device power profile number. The response will contain an ASCII code 1 ,2 ,3 ,4 or 5 representing device specific power profile number described below:Profile 1 : ~616 Kbps speed that draws no more than of max 75 mAProfile 2 : ~1080 Kbps speed that draws no more than of max 80 mAProfile 3 : ~1460 Kbps speed that draws no more than of max 85 mAProfile 4 : ~1700 Kbps speed that draws no more than of max 90 mAProfile 5 : Max speed that draws no more than 98 mA (factory default)The second byte in the response is the status byte |
w + 8 bit integer |
status byte | This 2 bytes command is used to set a new device power profile number. The 8 bit integer is a binary number for the desired power profile. After issuing this command the TL200 device will need to be powered Off and then On in order for the changes to take effect. The valid values are 1,2,3,4 or 5 as described below: Profile 1 : ~616 Kbps speed that draws no more than of max 75 mAProfile 2 : ~1080 Kbps speed that draws no more than of max 80 mAProfile 3 : ~1460 Kbps speed that draws no more than of max 85 mAProfile 4 : ~1700 Kbps speed that draws no more than of max 90 mAProfile 5 : Max speed that draws no more than 98 mA (factory default)There should not be delays longer than 90 milliseconds between moments when sending each byte, otherwise the device will ignore the commands. |
l + 16 bit integer |
Requested amount of 16 bit integers + status byte | This 3 bytes command is used to generate a sequence of non repeatable random integers from 1 to the specified range. The 16 bit integer used in command specifies the range for the sequence. The valid value for the range used with TL200 device is between 1 and 12000.1 For each 16 bit integer, the lower byte is sent first and then the higher byte. There should not be delays longer than 90 milliseconds between moments when sending each byte, otherwise the device will ignore the commands. |
User interactive mode (for Windows)
User interactive mode can be activated by sending the single character ‘u’ single character (command) to the TL200 device using GetRND software utility. The TL200 software kit contains the GetRND utility for activating the user interactive mode. In this mode, you can perform the following:
- Set a different power profile (5 power profiles are available based on speed vs power consumption)
- Enable or disable specific statistical start-up test
- Run statistical tests
- Generate frequency data reports for random sources
- Generate new user pass code
- Retrieve device unique serial number
FTDIChip-ID
Each TL200 contains a permanent, unique number known as an FTDIChip-ID programmed into the USB circuit that cannot be changed by the end user. This number can be used to develop applications that are tied down to specific devices. Click here for more information on this feature.
Other information
- Weight: 14 grams (0.5 oz)
- RoHS compliance: All parts and materials used in TL200 device are RoHS compliant
- Power consumption: The TL200 device draws no more than 98 mA (depending on the selected power profile)
- Operating temperature: 50° to 95° F (10° to 35° C)
- Relative humidity: 5% to 95%