Certificate-based vs PSK authentication — tradeoffs for embedded?
Certificate-based authentication uses X.509 certificates and public-key cryptography. The server presents its certificate, the client verifies it against a trusted CA certificate, and optionally the client presents its own certificate (mutual TLS / mTLS). This is the standard approach for internet-facing devices and cloud services. Tradeoffs: parsing and verifying certificates requires code space (~20-40 KB for X.509 parsing) and RAM (~5-10 KB for certificate chains). The asymmetric crypto is CPU-intensive. You need to manage certificates — provision a unique client certificate per device during manufacturing, bundle the server's CA certificate in firmware, and handle certificate rotation and expiration.
Pre-Shared Key (PSK) authentication uses a symmetric key shared between client and server during provisioning. The TLS handshake is dramatically simpler: no certificates to parse, no asymmetric crypto, no CA chain validation. A PSK handshake on a Cortex-M0 completes in milliseconds rather than seconds, uses 1-2 KB of RAM instead of 10+ KB, and requires minimal code. PSK is defined in RFC 4279 and supported by mbedTLS, wolfSSL, and BearSSL.
The tradeoffs: PSK has significant security and operational limitations. Each device must have a unique PSK provisioned during manufacturing — if a single key is shared across all devices, compromising one device compromises the entire fleet. PSK does not support server identity verification the way certificates do (you trust whoever knows the PSK). PSK does not provide forward secrecy unless combined with DHE (DHE-PSK cipher suites). And PSK key rotation requires touching every device. For small fleets with controlled provisioning (factory equipment, lab instruments), PSK is practical and efficient. For large-scale IoT deployments (thousands of consumer devices connecting to a cloud service), certificate-based mTLS with ECDSA is the industry standard — the upfront complexity pays off in scalable identity management, integration with cloud IoT platforms (AWS IoT, Azure IoT Hub), and proper forward secrecy.
Source: Networking Protocols Q&A
