Encrypted (Black) Keys and Ethernet Key Fill

I initially resisted implementing Black Keys due to the lack of secure memory on the Pi, but I have bitten the bullet and done so. My reasoning is that at worse it is no more secure than not using key encryption, and at best does improve system security.

The Black Key implementation uses Public Key Infrastructure. A Locked device can be created with a Private Key written to the SD card. Each device has its own Private Key. This Private Key can be encrypted with a Crypto Ignition Key which is written to a USB Drive or SD Card. It will be required to insert this Crypto Ignition Key into the Crypto Voice Module in order to decrypt the Private Key. If this is not done the Crypto Voice Module will be unable to decrypt Black keys.

Unencrypted (Red) keys are then encrypted by the corresponding device Public Key to produce the Black Key. The Black Keys can then be written to a SD Card or USB Drive or served over Ethernet. If a device is compromised the Public Key can be removed from the Key Fill/Generator device, and it will no longer be able to receive Keys.

A dedicated Key Fill device type was also added as part of this release. A Key Fill device does not need to have USB audio devices attached and can be used to generate keys and serve them to Crypto Voice Modules or other Key Fill devices using the Pi's Ethernet adapter. This Ethernet-based Key Fill does not require any Ethernet infrastructure such as switches or routers and can be done by directly connecting a Crypto Voice module to a Key Fill device using a simple Ethernet cable. The Ethernet-based Key Fill can only serve Black Keys.

Screenless Operation, Key Select and Rotation, and Device Deployment

This release builds on the objectives from the previous release:

• To make it possible to entirely configure the system with a newly flashed SD card installed in the system without needing to use the Windows utility (which still works and can still be used if desired)
• To make it possible to configure other identical devices with a configured device, as might be necessary when making multiple copies of a device
• To make it possible to generate a new encryption key and copy it to another non-identical device
• To make it possible to secure the device so it is difficult to modify or retrieve device configuration (including the encryption key) from a powered on device without an SD card installed

And adds a few more:

• To make it possible to use a configured device without needing to connect a screen or keyboard
• To make it possible to secure the device so it is difficult to modify device configuration from a powered on device with an SD card installed
• To make it easy to configure other identical devices with a configured device
• To make it possible to use more than one encryption key, and select between them
• To make it possible to transmit using Analog
• To make it possible to store and load encryption keys from a device which utilizes hardware-based security features.

The following features were added to support those objectives:

• Added support for storing/generating/saving/loading/selecting between multiple encryption keys
• Added support for headset volume control, plain/secure toggle, key load, key select, and TTS Alert Broadcast using buttons connected to the GPIO header
• Added support for configuring/using Push to Talk through the Console Interface
• Added support for saving encryption keys to, and loading keys from, a USB drive, including "secure" USB drives which use hardware-based encryption
• Added a concept of "Locked" devices which prevent a user from changing configuration and (optionally) using the Console Interface
• Added a streamlined deployment workflow for flashing "Locked" device images to SD cards. This workflow will format and flash a blank SD card with firmware, configuration, and (optionally) keys and permanently write protect the SD card (if supported by the SD card).
• Added a streamlined deployment workflow for flashing keys to SD cards and USB drives. This workflow will format and flash a blank SD card or USB drive with keys.
• Made Shell Access a development-only feature which is disabled in Release builds
• Added ability to password-protect the Configuration Menu
• Added support for two short (max 160 character) Text to Speech Alert Broadcast messages which can be broadcast over the radio
• Added support for broadcasting Plain (Analog) transmissions

With this release I'm attempting to give users who need a more secure device that option with the introduction of "Locked" devices. Locked devices don't have the ability to change configuration settings (or optionally use the display at all), and if using an SD card which supports the "permanent write protect" flag which is part of the SD card standard, it will not be possible to make changes to the SD card at all through software (it may still be possible through physically tampering with the SD card hardware). I highly recommend Locked devices being the norm when in the field, with one Unlocked device being used to configure them and issue them keys (while minimizing the amount of time that device operates with an Unlocked card).

The Locked workflow is optional, and by default devices operate in an Unlocked mode.

Numerous Bugfixes and Features

This release fixes two pretty significant bugs:

• A bug where the Push to Talk output signal was being "pulsed" instead of staying stable
• An intermittent bug (first reported by user testing!) in the 700C/D/E modes which could occur when receiving low SNR signals that caused the headset audio to "freeze"

There are also numerous new features added to the Configuration UI which I will try to go though. The overall objective of the Configuration UI changes were as follows:

• To make it possible to entirely configure the system with a newly flashed SD card installed in the system without needing to use the Windows utility (which still works and can still be used if desired)
• To make it possible to configure other identical devices with a configured device, as might be necessary when making multiple copies of a device
• To make it possible to generate a new encryption key and copy it to another non-identical device
• To make it possible to secure the device so it is difficult to modify or retrieve device configuration (including the encryption key) from a powered on device without an SD card installed

The following features were added to support those objectives:

• Added configuration options for the two radio squelch features: the Noise Gate/Modem Squelch which acts on the signal received from the radio and disables demodulation if the signal intensity is too low, and the FreeDV SNR Squelch which is based on signal quality and suppresses output to the headset if the signal quality is too poor.
• Added a configuration option to generate a new encryption key
• Added an option to disable the Configuration Utility when the device boots. If enabled the screen will show "Display Locked" without any ability to exit this screen
• Added the ability to exit the Configuration Utility by selecting an "Exit" option from the Main Menu or pressing Escape while on the Main Menu. Once exited the screen will enter the same "Display Locked" mode described above, and the device will have to be power-cycled to re-enter the Configuration Utility (unless it has been disabled).
• Added an Advanced SD Card Operations option which provides options for choosing which configuration files to read or write to/from an SD card. This option was designed to allow distribution of a particular configuration (eg. radio mode, encryption key) to non-identical devices.
• Added the ability to duplicate an SD card. This can be useful for rapidly creating multiple identical devices with the exact same version of the Crypto Voice Module software and configuration. Only the portion of the SD card used is duplicated.

The ability to copy a key from the device will perhaps be controversial. However this has always been possible if perhaps a bit difficult for someone unfamiliar with the system's internals. And I believe it is better to be honest about the fact that it is possible so that users can design security protocols knowing it is possible.

The ability to lock the display and disable the Configuration Utility should more than make up for this. If the display is locked, I am not aware of any way for someone to access the key through software. The only ways to access the key in that scenario I'm aware of are through the SD card (which is why I recommend not leaving an SD card in the system) and (I assume) by physically probing the memory on the processor chip (which is why the only secure key zeroize method is to disconnect power to the system).

Static Audio Device Assignment!

This release adds the ability for the user to bind an audio device in a particular USB port to either the Headset or Radio interface. This is done through a new "Assign Audio Devices" option in the Configuration Utility. Once this port assignment is performed and written to the SD card, it will no longer matter which order the OS initializes the devices. Any radio and headset volume settings previously written to the SD card should also carry forward once this is done.

This is an optional step, and if it is not done the system ought to behave exactly as it has before with the first initialized device being the headset device and the second being the radio device. However performing this step is highly recommended.

New Configuration UI!

This release provides a new console-based configuration UI which adds the ability to adjust FreeDV (radio) mode, encryption, and Push to Talk settings. It also adds diagnostic functions like displaying the OS startup messages in a navigation window and shell access for expert users.

The road to 1.0.0 is deferred a bit longer, but we are getting there; and a configuration UI (even a basic one as this admittedly is) is a major step toward that end.

Minor Power Improvements

This release adds some minor changes to the bootup and configuration process that should yield a slight reduction in power consumption.

Changes to the config.txt and startup scripts disable the power and activity LEDs

Changes to the config.txt disable the HDMI driver if no display is connected, and to not send a composite video signal over the analog AV port. Display of the rainbow "splash" screen was also disabled, to slightly reduce boot time.

Some minor improvements to random number initialization increase the speed at which the random number generator is initialized.

Major Redesign

This release is a significant overhaul of the underlying software architecture used by the system. The software now uses the JACK Audio Connection Kit to perform all transmit and receive operations. This change significantly reduces audio latency in the 2400B mode and hopefully will also improve system reliability.

System configuration has been overhauled, and the number of runtime configuration options has been significantly expanded. A new unified crypto.ini file replaces the crypto_tx.ini and crypto_rx.ini files from past releases. The previous release introduced the ability to selectively override certain default settings using configuration files on the SD card. This release carries that capability forward, except now the file must be named crypto.ini.

The hope is that this expanded configuration capability will reduce or eliminate the need to build custom SD card images, or use separate images for development and testing.

Push to Talk (PTT) functionality has been added which will enable/disable modem output to the radio based on an input on the Pi GPIO header and output a PTT signal from the Pi GPIO header to the radio. The radio PTT output has an automatic "hang time" feature which takes delays due to buffering and compression into account.

There is also a "modem squelch" feature which will disable signal demodulation from the radio if it falls below a configurable threshold.

When both these features are used CPU utilization drops significantly, which can potentially increase battery life in portable applications.

Notification sounds have been tweaked slightly. The normal startup sound has been changed, and when encryption is disabled an "alternate" chime is played instead of a text to speech notification.

This release only includes support the Pi 3B+

HF/SSB Support

This release adds support for the following HF/SSB modes supported by the codec2 library. Both encrypted and unencrypted communication is supported

• 1600
• 700C
• 700D
• 700E
• 800XA

This is in addition to the existing support for the 2400B VHF/FM mode that has always been supported by this project. More information on these modes can be found here

This release also includes an updated version of the codec2 library; all changes from the main branch were merged into the fork used by this project.

Support for the additional modes can be enabled by creating two files on the Pi SD card named config/crypto_tx.ini and config/crypto_rx.ini with the following contents:

[Codec]
; Supported values (default is 2400B):
; 1600
; 700C
; 700D
; 700E
; 800XA
; 2400B
Mode = 2400B
; Optional parameter in crypto_tx.ini to enable (analog) compression of the modem signal
; 1 enables compression
; 0 disables compression (default)
Clip = 0

Encryption can also be permanently disabled by adding the following lines to those same files. When encryption is disabled a warning message stating that encryption is disabled will play through the headset when the device powers on. Running with encryption disabled can be useful when trying to determine which mode is best for a particular application or troubleshooting transmission/hardware issues

[Crypto IO]
KeyFile =

Toggle Encryption

This release adds options to the configuration menu to disable encryption with the "p" key and re-enable it with the "c" key, followed by Enter. When encryption is turned off you should hear an announcement in the headset indicating this. No announcement is given when encryption is re-enabled

Maintenance Release

This release has no new functionality but simply updates buildroot to the latest version