Security
Security Features
Security is the top priority. Below is a table of security improvements that have been made since this project was forked from wifi-ap years ago:
| Security Feature | Antennas | wifi-ap |
|---|---|---|
| Maintenance | Actively being developed | Project abandoned in 2019. The last commit to master was on 2019-12-12 |
| Open Source | Yes, via Codeberg. Two-factor authentication and signed commits enabled. | Yes, on Launchpad |
| Hardware and Architecture | Only officially supporting Raspberry Pi 4b with arm64 and its builtin wireless chip. The overwhelming popularity of the Raspberry Pi makes it the lowest cost, yet most supported device available. Ubuntu certifies that it works with Ubuntu Core. It has the most stable wireless firmware I've ever experimented with. | Generically supports as many devices and architectures as possible. |
| Operating System | Only officially supporting Ubuntu Core which greatly improves security in ways such as an immutable base OS, confined applications, permissions, etc. Read more here and here. | Any operating system snaps can be installed on including less secure "classical" systems. |
| Base | Built with core24 (Ubuntu 24.04 LTS) as a base | Built with core16 (Ubuntu 16.04 ESM) as a base |
| Preferred Language | Rust was chosen for its memory and thread safety. Rust is compatible with ARM and snapcraft. | Go is also safe and compatible. |
| Application Interface | The application interface has been removed so that no other applications can directly control Antennas. | Allows other applications to communicate over a socket to control the access point and perform actions such as restarting the access point. |
| Unencrypted/Passwordless | Removed ability to configure an open access point. | Allows users to configure an open (passwordless) access point. Such an access point would have completely unencrypted wireless traffic. |
| Password Strength | 14 characters minimum, can't contain only numbers. | 8 characters minimum. |
| Password Storage | Stored as an encrypted PSK. | Stored as unencrypted plain text. |
| 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. | Unencrypted DNS through dnsmasq and default DNS. No malware blocking. |
| Third Party Software | Using updated versions of dependencies (hostapd, dnsmasq, dnscrypt, etc). Compiled from source with unused features disabled. All compilation changes are auditable from the snapcraft.yaml file. Compiled source code is downloaded directly from official source and not hosted elsewhere. Compiled source code is not built if it doesn't pass verification with sha512 checksums that have been GPG verified. | Several versions behind on software. Security vulnerabilities may be present. A copy of the dependency source code to compile is uploaded to a branch on the wifi-ap repository. Unknown amounts of code may have been changed before upload. Source code is not verified with checksums before build time. |
| 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. | User may define shell scripts that set/override "config", and is sourced by a shell script that the access point executes. User shell script may contain or be written to with arbitrary bash code. Must be root to set/get configuration via cli. |
| Services | Separate services are defined via snapcraft.yaml, each having their minimum required permissions assigned. | One monolithic service (Go server) that runs other services (hostapd, dnsmasq). All permissions must be assigned to the group. |
| Without Password | If a password is not set by the user, hostapd will not start. A randomly generated password cannot be used because the password is stored as an encrypted PSK. | A randomly generated password is set by default. |
| Virtual Interface | No virtual interface | Sets up a single virtual interface if option is set to do so. Could be useful for isolating guest networks, but that probably isn't possible without a USB wifi adapter based on the wifi's iw list output. |
| Firewall | Uses firewall for routing. Sets default drop policies with only required traffic allowed. Rate limits ssh connection. Uses nftables instead of legacy iptables. | Only uses firewall for routing purposes. Leaves default accept policies. |
| 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. | Same as Antennas. |
Cryptographically Secure Randomness
| 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. |
Unsafe
Antennas makes heavy use of the rust programming language. In rust, "unsafe" refers to code or interfaces that can't be verified as memory safe by the type system. Here is a list of our known unsafe usage:
| Unsafe | Reasoning |
|---|---|
| geteuid | To get the effective user id to require Antennas config to be run as root. Should not do anything dangerous with memory and should always succeed. I have confirmed that the source code for whoami and id both eventually call down to geteuid, so this should be as safe and easy as calling one of those commands. |
| tcsetattr | To interact with the termios (terminal) api to stop echoing a wifi password as it is being typed on the command line. This should make the application more secure by not displaying the user's wifi password. tcsetattr is not called directly by Antennas, and is called through a third-party dependency (currently dialoguer) |
| other | The setup binary makes heavy usage of calling to non-rust commands. Mostly nft and sysctl. Care is taken to only use trusted commands and to ensure a full path to the command is used. |
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.