How It Works
Contrary to popular belief it is essential that security is based on well known publicly reviewed methods and principles. As Auguste Kerckhoffs already stated in 1883, the security of a cryptosystem should depend on its key, not on its design being unknown to the attacker. The opposite approach, called “security through obscurity”, can easily lead to mistakes and vulnerabilities which the attacker can discover and exploit.
Therefore, we base our products on state-of-the-art encryption methods and protocols thoroughly reviewed by a wide cryptographic community.
Network communication
The entire CryptoCult's communication runs through the Internet. For traffic control (i.e. establishing and terminating voice calls, signalling contacts' availability, and delivering text messages), the Session Initiation Protocol (SIP) is used. Connection between the clients and the SIP server, which can be likened to a switchboard, is secured using the Transport Layer Security (TLS) protocol.
Voice calls
Security of voice calls is ensured by the Secure Real-time Transport Protocol (SRTP) used for data protection and the ZRTP protocol for key exchange.
The SRTP protocol provides protection against eavesdropping, data modification and replay attacks, i.e. inserting previously recorded data into the data stream. Data are encrypted using the AES-256 cipher and their integrity is verified using the HMAC-SHA1 checksum. Master keys, from which keys used for actual encryption and verification are derived, are negotiated via the ZRTP protocol.
The ZRTP protocol enables secure key exchange without requiring a pre-shared secret, i.e. a secret known to both parties beforehand, for communicating parties' mutual authentication. Diffie-Hellman key exchange, which enables establishing a shared secret while communicating over a public channel, is used as a first step.
To provide protection against the man-in-the-middle attack, an attack where the attacker actively enters the communication and impersonates the communicating parties, verification of the fact that both parties obtained identical shared secret is required. To achieve this goal, a checksum of the shared secret is calculated and displayed in the form of a four-letter code, called the Short Authentication String (SAS). This code is read aloud by both parties at the beginning of a call. A mismatch indicates the possibility of a man-in-the-middle attack and the call must be immediately terminated. If there is a history of calls between the parties, an additional layer of protection is provided by incorporating some information derived from previous sessions into the shared secret.
All keys used during the call are destroyed after the call is terminated. This ensures perfect forward secrecy; captured encrypted data cannot be decrypted even if a communicating party's device is later compromised or if one of the communicating parties is forced to cooperate with the attacker.
Text messages
Text messages are secured according to the OpenPGP standard. OpenPGP is based on asymmetric cryptography. Every user has a key pair consisting of a public and a private key. As the name suggests, the public key is to be published. Any user can then use this public key to encrypt a message which only the holder of the secret key will be able to decrypt.
CryptoCult's implementation of the OpenPGP standard supports the RSA cipher for all operations, i.e. encryption, decryption and signing of messages, the ElGamal cipher for message encryption, and the Digital Signature Algorithm (DSA) for message signing. A wide range of symmetric ciphers used for protecting the message content itself is supported. The AES cipher with key lengths of 128, 192 and 256 bits, and the CAST5 cipher are fully supported. Decryption of messages protected by the 3DES and TwoFish ciphers is also supported.
CryptoCult enables you to generate your own PGP key (RSA) securely inside the application; you do not need to rely on third parties' products to perform this task. If you already have your own PGP key generated by another application, e.g. GnuPG or PGP Desktop, you can easily import and use this key with CryptoCult.
E-mails are, like text messages, secured according to the OpenPGP standard. CryptoCult's integrated e-mail client supports standard protocols for e-mail exchange, POP3, IMAP and SMTP. These can be secured using the TLS protocol. Establishing encrypted communication using the STARTTLS protocol is also supported.
Application data
To prevent unauthorized access, both application data and user data stored in the Trezor data vault are encrypted using the AES-256 cipher. The encryption key is derived from user's password using the PBKDF2 function. To ensure security, 160 bits of cryptographic salt are added and 4096 iterations of the HMAC-SHA-256 hashing function are carried out. This method of key derivation provides increased protection against attacks on the user password, which is typically the weakest point in the system.
Randomness source
A high quality source of randomness is essential for any cryptographic application because even the strongest cipher cannot protect the data if the key it uses can be guessed by the attacker. Therefore, we have also paid special attention to this area.
Truly random data are relatively scarce; the required amount is not always readily available. Therefore, so-called cryptographically secure pseudorandom number generators are used. Using truly random data as input, these can produce a large amount of data which is, by all practical means, indistinguishable from truly random data.
In our application we use Fortuna, a cryptographically secure pseudorandom number generator. The generator is seeded with random data originating from the phone's camera, the sound input during a voice call, and the timing of user actions. Its design ensures that even if some of the randomness sources are lost or compromised (e.g. by overexposure of the camera during random data collection), the quality of resulting output data is not compromised.
