top of page


Your source for insights from our team on secure communications and encryption,
as well as tips and tricks to get the most from using Cellcrypt

Cryptography: Hardware VS Software

In today's digitized age, securing our mobile communications is paramount. With threats from hackers, malware, and other cyber vulnerabilities ever on the rise, a plethora of solutions have been proposed. But is hardware the answer? Let's delve into the pros and cons of hardware-based security solutions.

Secure Mobile Devices

A dedicated secure phone can prevent malware infections by not allowing third-party software. These devices may also include hardware protective measures against tampering in the event of theft or loss. However, users are forced to carry two communication devices i.e. they still need their mobile phone for general use.

Dedicated crypto phones are expensive and upgrades are very rare. A good example that highlights this problem is the recent exposure of the Terrestrial Trunked Radio (TETRA) cryptography vulnerability. It will take years to replace existing TETRA phones. The biggest problem with dedicated security phones is that small market economics prevent vendors keeping up with technology creep and contemporary aesthetics.

SD Cards

Some security companies offer hardware security for mobile phone communication in the form of a microSD card or some other removable crypto device. This has very limited security value since it cannot control the user interfaces and malware can just as easily use the security device by capturing the device PIN entered by the user. It doesn’t really matter if the encryption keys are protected by hardware if malware can access the human interfaces since the malware can record and transmit speech and key presses or even manipulate display information, all without requiring the use of the hardware security device.

One might argue that a secure SD card protects user’s keys in the event of theft or

loss of their mobile phone but it’s more likely that the secure SD card will be stolen together with the phone. Therefore, one must compare the effort required to physically break into the SD card as opposed to retrieving keys off a stolen phone based on software-protected keys. With a software-only approach the attacker still must mount a hardware attack on the phone to get past the phone’s PIN/fingerprint controls and applications can also derive keys from a user’s password using the standard Password-Based Key Derivation Function (PBKDF2). The PBKDF2 approach can be much stronger than hardware protection alone. There are numerous examples on the Internet of smart card and SD card “tear-downs”. These can be done a lot quicker than a brute-force attack on a PBKDF2-encrypted key.

Secure messaging apps often require multiple asymmetric crypto computations in quick succession e.g. when downloading messages after being offline. SD cards and other external security devices are too confined and temperature-sensitive to support processors capable of competing with the multi-core high-performance processors found on smartphones and will prove to be too slow for these kinds of applications.

Compatibility and technology creep

Market drivers often combine to motivate industry to change external interface standards. Technology creep is a major obstacle for hardware security devices. This was the unfortunate experience of hardware crypto designers in the early days of PC’s with bus and peripheral interface standards changing quite often. It takes a long time to develop and certify high-security hardware devices.

Secure cryptographic protocols

The theft of crypto keys is not necessarily always a disaster. Some crypto protocols are designed with properties that include Perfect Forward Secrecy (PFS). In a secure speech application, the goal of most attackers is to monitor conversations in an undetectable way. With PFS this cannot be achieved purely by compromising a user’s long-term private keys. A decent key agreement protocol can, therefore, reduce the need for high-security protection of keys and thus reduce the need to consider hardware security.

bottom of page