Security
Security Features
Security is the top priority. A wifi router that isn’t secure isn’t worth using. And we’ve made significant improvements to security over the years…
| # | Security Feature | Antennas |
|---|---|---|
| 1 | Maintenance | Actively being developed |
| 2 | Open Source | Yes, on Codeberg. Two-factor authentication and signed commits enabled. |
| 3 | Hardware | Only officially supporting Raspberry Pi 5 and its builtin wireless chip. The device does not reach end of life until 2036-01-01. Its wireless firmware has been promptly patched when issues are found. Ubuntu certifies that it works with Ubuntu Core. |
| 4 | Operating System | Only officially supporting Ubuntu Core 26 which greatly improves security in ways such as an immutable base OS, confined applications, permissions, etc. Read more here and here. |
| 5 | Base | Built with core26 (Ubuntu 26.04 LTS) as a base |
| 6 | Programming Language | Rust was chosen for its memory and thread safety. Rust is compatible with arm64 and snapcraft. |
| 7 | Application Interface | The application interface has been removed so that no other applications can directly control Antennas. |
| 8 | Wifi Encryption | Removed ability to configure an open, unencrypted access point. |
| 9 | Wifi Password | 14 characters minimum, can’t contain only numbers. Password is not shown when typing it. Encrypted and NOT stored as plain text. Memory is properly zeroed after both prompting and encrypting a password. |
| 10 | DNS | Encrypted with DNS-over-HTTPS using TLS 1.3. Pi 4b uses TLS_CHACHA20_POLY1305_SHA256 and Pi 5 uses TLS_AES_128_GCM_SHA256. DNS encryption verified with this tool. DNS-level blocking of malware. DNS rebind attacks blocked. |
| 11 | Third Party Software | Using updated versions of dependencies (hostapd, dnsmasq, dnscrypt, etc). Each is downloaded from its official source, verified with sha512 checksums and GPG signatures, and only then compiled with unused features disabled. Any compilation change, such as disabling a feature, is auditable/reproducible from the snapcraft.yaml. |
| 12 | Config | The only way to generate config is through the bundled rust program. Config is stored in non-executable toml format and validated before use. File permissions are limited. Must be root to set/get config via cli. |
| 13 | Services | Separate services are defined via snapcraft.yaml, each having their minimum required permissions assigned. |
| 14 | Firewall | Uses firewall for routing. Sets default drop policies with only required traffic allowed. Rate limits ssh connection. Uses nftables instead of legacy iptables. |
| 15 | Web Interface | No web interface. Config is only accessible through key-protected SSH. This eliminates the possibility of a website to brute-force guess the router’s web interface credentials. |
Hardware Cryptography
| Pi 4b | Pi 5 | Notes | |
|---|---|---|---|
| Hardware Random Number Generator | Yes | Yes | Can be accessed by sudo cat /dev/hwrng. /dev/hwrng should be feeding the pool that /dev/random and /dev/urandom pull from. System entropy can be checked with cat /proc/sys/kernel/random/entropy_avail. Testing the RNG on both devices outputs what I interpret to be the same results. I’ve tested with both rng-tool’s sudo cat /dev/hwrng | rngtest -c 1000 and dieharder’s dieharder -a. |
| Cryptographic Hardware Acceleration | No | Yes | The Pi 5’s acceleration allows it to use AES algorithms for DNS (see table above). |
| Cryptographic Operation Benchmarks | PBKDF2-sha512 (256b): 482,769 IPS aes-cbc (128b): 94.7 MiB/s encrypt, 99.2 MiB/s decrypt aes-cbc (256b): 76.2 MiB/s encrypt, 77.9 MiB/s decrypt aes-xts (256b): 90.3 MiB/s encrypt, 102.5 MiB/s decrypt aes-xts (512b): 79.2 MiB/s encrypt, 80.0 MiB/s decrypt | PBKDF2-sha512 (256b): 958,478 IPS aes-cbc (128b): 982.1 MiB/s encrypt, 1613.4 MiB/s decrypt aes-cbc (256b): 810.3 MiB/s encrypt, 1379.9 MiB/s decrypt aes-xts (256b): 1351.7 MiB/s encrypt, 1352.9 MiB/s decrypt aes-xts (512b): 1199.8 MiB/s encrypt, 1199.3 MiB/s decrypt | Run with command: cryptsetup benchmark, which is preinstalled on most linux systems. Only a subset of results shown, run the command to see the full results. |
Memory Safety
Approximately 70% of security issues are memory safety issues. Antennas makes heavy use of the Rust Programming Language which enforces memory safety at compile time. In Rust, the only way to write code that isn’t verified as memory safe is to explicitly mark the code as “unsafe”. Unsafe usage is rare and Rust code tends to be much safer than alternative code.
Antennas itself is 100% memory safe and forbids the usage of unsafe. The same applies to its dhcpv4 server (toe-beans) and its password encryption (wpa_passphrase). The only exceptions are:
- Third-party libraries used by Rust programs that forbid unsafe may use unsafe. I’ve made progress on reducing this, and again, its still less than using alternative software.
- The setup binary currently configures the system by calling other non-rust programs. Mostly
nftandsysctl. Care is taken to only use trusted commands and to ensure a full path to the command is used. - Other daemons that Antennas starts such as
hostapdanddnsmasqare written in C and are not memory safe.
Other
- Verified that swap storage is off by default (via
swapon --show). This is good when without full disk encryption and without encrypted swap. - USB devices are not auto mounted.