A software-defined radio can contain programmable logic, processor firmware, waveform software and cryptographic functions. Each protects or controls a different part of the system. To evaluate a security claim, identify the asset, the threat, the mechanism and the evidence for that exact device and configuration.
On a narrow screen, swipe tables sideways or focus them and use the arrow keys.
Name the boundary before naming the algorithm
| Asset or action | Relevant protection | Evidence to request |
|---|---|---|
| Proprietary FPGA configuration | Bitstream encryption and controlled key provisioning | Device-family configuration guide and enabled mode |
| Code admitted at startup | Authenticated boot and a defined trust anchor | Boot-chain documentation and verification behavior |
| Software updates | Authenticated update process and version policy | Signing, recovery and any rollback-control documentation |
| Operational secrets | Key storage, access controls and lifecycle management | Security boundary, provisioning and replacement procedures |
| Traffic crossing a radio link | Protocol-specific communications protection | Supported mode, endpoints, key management and applicable validation |
Encryption protects confidentiality; authentication addresses whether data came from an accepted source and remained intact. The combination and its implementation matter. A statement that a radio uses AES needs a second sentence explaining which data AES protects and where the keys reside.
Altera’s partial-reconfiguration documentation separates bitstream validation, authentication and encryption for specified Stratix 10 and Agilex 7 designs. That separation is a useful reading framework; those features belong to the documented device families.
Read the Stratix II example in its own period
The Stratix II Device Handbook (PDF) describes decrypting configuration data using a 128-bit AES key held in the FPGA, with a nonvolatile storage option. This protects the configuration supplied to the device and helps explain why a radio designer would use the feature when distributing proprietary designs through manufacturing partners.
The relevant question is protection of the implementation delivered to the FPGA. Voice or data sent through the air follows a separate signal path and requires its own communications-security design. Likewise, modern boot or update functions must be verified against the exact hardware generation; a newer family’s security table cannot establish an older chip’s capabilities.
Follow the software lifecycle
- Build and release: identify approved source, toolchain and artifact
- Provision: establish trusted keys and device identity
- Boot and update: verify admitted code and configuration
- Operate and recover: monitor faults, protect secrets and restore trusted state
NIST SP 800-193 organizes platform firmware resilience around protection, detection and recovery. For an SDR, use that framework to ask what happens after an interrupted update, a rejected image or corrupted persistent state. A device that rejects an invalid image also needs a documented route back to a usable trusted state.
Record which component makes each decision. A host computer may verify a download while the radio independently verifies what it loads. An FPGA may accept a configuration while a processor boots a separate firmware image. Draw those as separate boundaries, with the communication between them visible.
Turn a vague claim into answerable questions
The answers should include document revisions, hardware identifiers and test evidence. Keep unresolved questions explicit. A brochure can name a capability while a security guide defines the enabled settings, assumptions and limitations.
Read validation claims at their stated scope
FIPS 140-3 addresses cryptographic modules and their defined interfaces, roles, operating environments and other security requirements. A module validation is evidence about a specified module under stated conditions. Evaluate the surrounding radio, software, key handling and deployment against their own requirements.
A practical review ends with five linked records: the system diagram, an asset/threat table, exact versions and enabled settings, the vendor’s supporting documents, and results for authorized validation tests. Keep secret key values out of that ordinary review record. Revisit it when firmware, FPGA images, provisioning, ownership or supported security modes change.