Resilience Theatre

Personal projects for resilience

User Tools

Site Tools


secureptt:introduction

Secure PTT

This page presents technical details about 'Secure PTT' project for embedded Linux targets. You can find this project at my Github page.

This project is available with SBOM listing required by EO14028 and includes CISA Secure Software Development Attestation form template, which you can use as base for your own build submission.

Reasoning for Secure PTT is to show how OTP (one time pad) can be viable alternative for ciphering when you need to deliver unbreakable encryption but cannot hand out classified algorithms. This is perfect solution to compile inside your mesh radio or tailor into your tactical nodes.

After you issue that gstreamer command on PC which is on same network as your MESH radio PTT is, you realize that you need some encryption to your PTT comms. Multicast transmitted voice without encryption is really a bad thing.

Secure PTT also serves an example which you cannot implement meaningfully on consumer operating systems and platforms. They do not support required technologies and ultimately they cannot secure key material to proper level. So get TAK from 'Google Playstore' and security from here.

Raspberry Pi serves here as an example of ARM target where you can train your developers to do cross compilation. Having all source code and compiling in house operating system (and applications) is new era towards EO 140281) compliance.

Remember always ask one question: 'Who has compiled my kernel?'

Radio manufacturer, make it better

If you're manufacturing those radios, pay attention to encryption, cyber security and OPSEC. My code can secure also your PTT implementation in so many different ways.

Introduction

Secure PTT is small embedded linux firmware for RPi4 which implements Push-To-Talk over One-Time-Pad secured channel. This project is not a ready product or complete system, but technology preview what you can achieve with embedded domain where secrecy of PTT communication is priority.

My demo setup uses VPS which routes packets between nodes when they are located behind carrier grade nat (CGNAT) and point-to-point connection cannot be established. This makes it easy to test solution in mobile networks and various other WAN setups. If you are using MESH/MANET networks like AN/PRC-169 - you can configure Secure PTT to work without gateway.

Gateway only routes packets between nodes and does not contain any storage or other functionality.

Features

  • Full source code build of Operating System (OS)
  • Small and robust firmware approach (instead of OS distributions)
  • Push-to-talk with One-Time-Pad (OTP) encryption
  • Out of band keyed OTP from true random number generator (TRNG)
  • Small scale high security implementation
  • OPUS speech encryption with forward error correction, allows 20% packet loss.
  • Unicast or multicast UDP with layered transport
  • Less than 20kbit/s bandwith requirement
  • Crypto agile

Payload protection (One-Time-Pad)

“In cryptography, the one-time pad (OTP) is an encryption technique that cannot be cracked, but requires the use of a single-use pre-shared key that is larger than or equal to the size of the message being sent.” 2)

Secure PTT encrypts speech streams with OTP and requires out of band keying over physical delivery.

Protect the user

As encryption protects the payload, meta-data obfuscation protects the user. Current implementation has three layers to protect speech data encoded with OPUS codec and outermost layer obfuscates traffic based on operational requirements.

Layer Technology
A FakeTCP or RTP packets
B Wireguard
C One-Time-Pad encryption

Kenwood SMC-34

Wire up Kenwood SMC-343) monofone for RPi4 with Codec zero4). Note that using Codec Zero has currently around 1 second delay before audio path is open from Codec. I am checking reason for this, but it's bit slower than USB audio device currently. There is now patch available to remove that one second delay.

Disclaimer

Encrypting Push-To-Talk traffic is a challenging thing. I have done implementations with symmetric algorithms and One-Time-Pad, like illustrated here. With symmetric algorithms you can scale better but with One-Time-Pad you get better security. Typically OTP is used with low peer count with exclusive access to this level of security, while rest of the team could use symmetric algorithms.

Being crypto agile is main advantage what you get from this approach.

Secure Software Development Attestation template

The software is developed and built in secure environments. Those environments are secured by the following actions, at a minimum:

Attestation itemMethod used Notes
1) The software is developed and built in secure environments. Those environments are secured by the following actions, at a minimum: Dedicated Linux workstation
a) Separating and protecting each environment involved in developing and building software; MacSEC separated network segment
b) Regularly logging, monitoring, and auditing trust relationships used for authorization and access:
i) to any software development and build environments; and
ii) among components within each environment;
External logging server behind data diode
c) Enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimizes security risk; 2FA login and sudo access with FIDO2 hardware key
d) Taking consistent and reasonable steps to document, as well as minimize use or inclusion of software products that create undue risk within the environments used to develop and build software; Isolated environment has no email, IM or connected cloud services
e) Encrypting sensitive data, such as credentials, to the extent practicable and based on risk; No production primitives stored or used on development workstation
f) Implementing defensive cybersecurity practices, including continuous monitoring of operations and alerts and, as necessary, responding to suspected and confirmed cyber incidents; MacSEC segment has active honeypot and monitoring
2) The software producer makes a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities; All remote source code repositories are locally mirrored and in case of update, build system does hash checking against released source.
3) The software producer maintains provenance for internal code and third-party components incorporated into the software to the greatest extent feasible; Internal repositories are monitored and located to development workstations. All external components are monitored via produced SBOM
4) The software producer employs automated tools or comparable processes that check for security vulnerabilities. In addition:
a) The software producer operates these processes on an ongoing basis and prior to product, version, or update releases;
b) The software producer has a policy or process to address discovered security vulnerabilities prior to product release; and
c) The software producer operates a vulnerability disclosure program and accepts, reviews, and addresses disclosed software vulnerabilities in a timely fashion and according to any timelines specified in the vulnerability disclosure program or applicable policies.
Build system has ability to create SBOM and cross reference to official CVE databases. These results are evaluated before every software release.
secureptt/introduction.txt · Last modified: 2024/11/22 03:59 by admin

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki