The Crypto Bone

privacy and secure communication
under your control

     
 

Attacks On The Crypto Bone

How can the Crypto Bone be attacked by an opponent? Let's have a look at the following scenarios:

Attacks on the Message Exchange

An attacker can destroy messages, that have been sent out or he can modify messages that are waiting to be processed, if the attacker takes over the victim's email account or if he could change emails in transit. This is not too difficult and will certainly be a real risk that the design of the Crypto Bone has to take into account.

Destroyed messages are lost, as the Crypto Bone does not store messages already sent, because they have been encrypted with keys that will most certainly not be in use after a destruction has been discovered. At the moment there is no automatic receipt, that would indicate that a message did not arrive. If the communication channel is still secure, i.e none of the two participants have been "hacked", they will discover that information didn't get through to the other side and resending the lost information may be requested by either party. This would result in a new message exchange, using new keys and the clear text has to be re-entered into the system. As may other systems, the Crypto Bone is not immune to willful disruptions.

Modifications of the encrypted messages are possible by a man-in-the-middle, but only messages that are encrypted with one of the keys stored in the key database will be accepted by the Crypto Bone on either side. Using the correct key for encryption is proof of the sender's authenticity, because the sender had received the correct next key inside an encrypted message, that the recipient had sent before. Without a knowledge of one of the plain texts, an opponent cannot learn the encryption key that will be used next.

Modified messages sent by a Man-in-the-Middle are essentially treated as spam, because they cannot be decrypted inside the Crypto Bone and consequently don't end up in the user's mailbox.

As cryptlib-3.4.3 is used for symmetric encryption, the next encryption key is protected by AES-128 in Cipher Feedback (CFB) mode. Even though the position of the next key (last 40 Bytes) in the plain text is known, the next key is protected against manipulation as reliably as any other byte of the plain text. Any attempt to manipulate the next key will result in an unsuccessful decryption and will only lead to a loss of a message, similar to a destruction of the whole message.

Attacks on the Encrypted Tunnel

The basic idea behind using the External Crypto Bone assumes, that the user's end-point device is less secure than the Crypto Bone and that the user's local area network is not trustworthy. As all plain text information enters or leaves the Crypto Bone encrypted, the security of the SSH channel to the Crypto Bone is the weakest link.

To be able to operate the Crypto Bone with the cryptobone GUI program, a user has to establish a SSH connection with a private ssh key, so this RSA key "cbb" must be available on the user's end-point device. It's a crucial point to make sure that the stored keys are unavailable to malware that runs on the user's end-point device on behalf of the user. It is not enough to separate these crucial keys by means of file permissions only. That's why in version 0.99e the central cryptobone daemon is introduced.

The daemons job is to store the masterkey and the ssh private key in memory during the lifetime of a login session and to use these secrets to establish the secure tunnel to the External Crypto Bone. To minimise access to these keys, they are stored in an encrypted file system that is only mounted for a tiny period when the Linux computer is booting. After reading the keys from the encrypted file system the file system dissappears and is not available until the computer is rebooted again.

An adversary with the ability to read files as the root user must attack the system at boot time or the adversary has to gain full root privileges on the Linux computer to re-mount the encrypted file system, in order to learn anything about the secret keys. This approach does not make it entirely impossible to compromise the secret keys, but it raises the bar quite high with respect to the abilities an adversary needs to establish on the Linux computer.

Endpoint exploits, especially root kits, do put the whole system at risk.

If the local, software-based Crypto Bone is used instead of an external device, it is crucial to know that the cryptobone daemon communicates via a root-read-only socket with the graphical program and that the user needs to enter his login password to make this communication possible via the sudo mechanism. The daemon will terminate any communication attempt that does not originate from the one single program (cbcontrol) that is allowed to send commands to the daemon. It always checks whether the program "cbcontrol" is the communication-process' parent process or not.

If an attacker tries to exploit user code to access the cryptobone daemon using the network interface it is neccessary to elevate execute permissions via sudo for which the attacker needs the user's login password. A successful malware exploit that compromises the user's login password may then lead to an impersonation of the user but would not result in a compromise of the master key that protects the message key database stored on the Linux machine unless the adversary gains full root privilege.

Storing the message key database on a separate, external device, be it a second Linux computer or a Beagle Bone / Raspberry Pi has the advantage that an adversary would need to compromise a second device even if he has gained full root privilege on the main Linux machine. So it's also fair to say that in this case, without access to the External Crypto Bone's file system, where the encrypted message key database is stored, the knowledge of any such key available in the user's endpoint device does not reveal the message encryption keys that are currently in use.

Attacks on the Base System

One of the major parts of the base system is the SSH daemon. If an attacker can exploit any back-door built into this daemon, the encrypted tunnel becomes insecure. This highlights the necessity to audit all of the major parts on which the Crypto Bone's security relies, in particular the trustworthiness of the random number pool (/dev/random) and of course the cryptlib binary. Note, that the Crypto Bone uses only a tiny fraction of the whole cryptlib functionality, because only the PGP enveloping code is required. So the cryptlib binary may be reduced considerably in future versions.

Physical Attacks

What, if an External Crypto Bone is stolen?

As the "masterkey" is stored in the cryptobone daemon of the main Linux computer, it will be transferred to the external Crypto Bone when the Linux system boots up. So, a stolen external Crypto Bone leaves the encrypted key database secure because a powered-off external Crypto Bone will not store any plain text messages either. During it's normal operations the decrypted messages are stored in the RAM disk only as long as the user has not read and deleted them. If an adversary manages to steal a running Crypto Bone and keep it powered, the stored secret information is present in the main memory only and never stored in the file system.

In case the external Crypto Bone including the main Linux computer has been stolen, the message keys, that are currently in use, are all compromised and a user must contact all of her correspondents and ask for a reset of her account. That would require deleting her key by replacing it with the initial secret or by agreeing on a new initial secret with all her correspondents.

The same situation occurs when the main Linux computer that uses the local, software-based Crypto Bone is stolen. So, if that's a serious risk in your special situation, you may consider to always use an external device that is physically more secure and still reachable through your local network. This might not be an option, if you travel a lot.

This master key compromise does not affect past messages, that have already been read, because the message keys are no longer active and forgotten. But when the system has unread messages for the user and is going down for reboot, the unread messages are being saved and are stored encrypted inside the key database. With a compromised masterkey, these messages are vulnerable, if the adversary has physical access to the external Crypto Bone and the user's main Linux computer.

Usable Security

One of the main reasons why people still don't encrypt their emails is the complexity of the process and the inability to understand let alone control the processes involved.

The Crypto Bone does not only reduce this complexity by integrating the cryptographic engine into a well-designed, minimalistic and highly auditable, separate device, that does all the hard jobs, it realizes a new approach to key management, too.

A user should not be forced to install special software on his end-point device, nor should he need to configure a complex system, that would eventually become more insecure with every decision he can get wrong. A secure and usable system should help the user to play his own part well, it won't take away the user's control over the system, and it would not burden him with unnecessary parts of the key management.

That's why the Crypto Bone allows to set an initial secret for a prospective correspondent and to reset this secret, if need be. It maintains the user's control over the system and enables the user to define which correspondent he trusts. But bookkeeping of message keys and generating secure keys for the ongoing flow of secure messages are best done inside the Crypto Bone automatically.

In my view, under no circumstances should the crypto engine make encryption transparent to the user, in the sense that the user does not even see that the messages he sends out are encrypted nor should it take away the user's ability to stop a particular message exchange from happening.

8 November 2016