The common suspicion that most security products these days contain backdoors may be partly justified. Backdoors have probably existed in many software products for years, but only recently the problem starts getting a wider attention. Many users were shocked to discover that spying code was a pretty common part of the products that they were using on the everyday basis.
It is generally believed that open-source code solves the problem completely. Unfortunately, in real life things are never that simple.
- With full access to the source code it is easy to create a version of the program with a backdoor inserted. Replacing the authentic program on the user’s computer with the forged copy may be hard but far from impossible.
- A determined individual can participate in the development of the program – open-source projects are usually open for participation. Contrary to popular belief, a carefully added weakness is very hard to find even in an open and actively developed code – history shows that many security holes in open-source products existed for years and were found only after being exploited. We can only guess how many ones are still being used quietly.
Kryptel and Silver Key encryption engines are now open-source, and in the development of Kryptel 8 and Silver Key 5 we put our efforts in preventing these scenarios.
What is a Backdoor
In general, backdoor is a hidden feature that allows accessing user’s data without user consent, which in case of encryption software means without having the right key.
Both Kryptel and Silver Key are offline programs; if a forged copy tries sending any confidential data to the hypothetical backdoor owner, such unusual activity will easily be detected. The only way for an offline encryption program to implement a long-living backdoor is to weaken encryption by hiding the key data somewhere inside the encrypted file.
Where a backdoor may be hidden
Ciphers use a random value to initialize a new encrypted stream. That value is called initialization vector. Kryptel and Silver Key use a lot of them (a different one for each encrypted file), but they are stored in the encrypted directory and are not available to a hacker. The only exception is the top-level vector – we need to know it in order to start decryption so the directory init vector has to be stored in the open. That vector may contain any data and a forged encryptor could store there a part of the key instead of a true random value.
Kryptel 8 and Silver Key 5 do not generate a random directory init vector and no more keep that vector in the header. Instead they derive the vector from the excess bits of the key material. This method not only removes a possible backdoor but also increases the encryption strength because the vector is now secret.
Every binary key file has a unique 128-bit key identifier. The previous versions stored that key ID in the container header so that the decryptor could recognize the right key. A fake key creation program could use a part of the key as the key identifier thus decreasing its strength. That would hardly be critical though because the length of binary key is 4096 bits and leaking just 128 of them will not be of much help for an attacker. Still it was a potential weakness that was better be removed.
Kryptel 8 and Silver Key 5 completely ignore binary key IDs and do not store them anywhere. In order to determine if the key is correct, they compute a special verificator, which cannot be used for inserting a backdoor.
Yubikey could also be used to inject backdoor data. Yubikey uses a 512-bit random challenge that is to be sent to Yubikey in order to receive the corresponding encryption key. The challenge is stored in the encrypted file’s header. On the first glance this scheme seems to be safe because the Yubikey’s encryption key depends on the challenge value. Storing key information in the challenge is impossible as that would invalidate the key.
However this is true only when the data is encrypted with a single Yubikey. When Yubikey is a part of a complex key, a forged encryptor can use that unnecessary large challenge field to store the other subkeys and thus to provide a full size backdoor.
Kryptel 8 and Silver Key 5 do not generate random challenges anymore and do not keep them in the header. Instead they use the common 64-bit salt value, extending it to 512 bits with zeros. Although 64 bits provide much less variety than original 512 bits, they are quite sufficient for a secondary non-key value.
The standard method of implementing more complex key schemes is based on using a session key. The program generates a random session key, which is used as the actual encryption key. The session key is then encrypted with the user-provided keys and the result is stored in the header.
While this two-level method is convenient and is sometimes necessary, it creates a huge security hole. A forged encryptor may take the session key from a list of keys set by the attacker. The worst part is that there is no way to determine whether the session key is a honest random value or just looks this way.
Solution for Composite Keys
There is no problem with composite keys at all. Although the previous versions used a scheme with a session key, it was not really necessary. Kryptel 8 and Silver Key 5 do not use session keys, deriving the encryption key directly from the composite’s subkeys.
Solution for Key Groups
Things get more complicated in case of key group. We cannot avoid using session key and so there always exists a possibility that it has been tampered with. Still the situation is not hopeless. While it is not possible to prevent the key from being forged, it is possible to recognize a forged key.
Kryptel 8 and Silver Key 5 do not use random session keys. Instead they derive the session key from all the group subkeys. If Password Manager knows all the subkeys (it does, if the file is being opened on the same computer), it re-computes the session key and verifies that it was produced correctly. If the key has been tampered with, Password Manager notifies the user.
File forged.edc is encrypted with a forged (all zeros) session key. The key group consists of two passwords: abc and xyz. If you open the file with any of these passwords, it will open normally as one subkey is not enough to detect a forged session key. However if you add both the passwords to Password Manager's database, the program will detect tampering and will displays a warning message.
Exploiting Unused Tails
The size of Kryptel 7 and 8 container file must be a multiple of 4096 bytes. Because the file data is very unlikely to have exactly the needed size, there always are unused bytes at the end of the file. In theory, that unused area may be used to hide key information. In practice, the tail is filled with special fill bytes, and presence of non-fill data will immediately be detected.
Silver Key parcel does not require any alignment, however it allows including arbitrary data before and after the parcel body. Silver Key 5 encryption engine is no more allowed to add random obfuscation data; a created parcel with any non-parcel data included should be considered compromised. Obfuscation data however may be added using the Repacker utility, which does not have any access to the key data and so is safe to use.
Holes in the Data Area
Normally container’s data area does not contain any unused space. However if such a hole does exists, it will not affect normal container operation. A forged encryptor could insert a block of the key information between two encrypted streams. However in practice this place is not fit for this purpose. First, when the file gets open, the storage handler collects very detailed container statistics. A discrepancy between the data area’s actual and occupied size will immediately be detected. Second, such a hole will automatically be removed on the next container compression operation.
The same is true for Silver Key parcels – although data chunks inserted between encrypted streams do not affect decryption, their presence can easily be detected.
Kryptel 8 container and Silver Key 5 parcel formats do not have any weak spot that could be used to insert a hard-to-find backdoor. Although it is still possible to embed the key data using a forged copy of the program, such a backdoor can easily be detected.