TrueCrypt alternatives for Windows, Encrypted Container Systems

A colleague recently asked me “what encryption solution should I now use instead of TrueCrypt?”. After a couple of questions back-and-forth we defined the request to :

have a simple to use, reliable encryption system for individual containers on Windows platforms in a corporate environment

Easy sharing

The containers have to be easy shareable with multiple users, preferably via a cloud storage provider.

Typically users share encrypted containers by emailing them or copying them to removable media. With the popularity of free cloud storage providers users started to share these containers via the cloud. There’s a problem with that. Most of the cloud storage providers have some sort of utility that syncs a users’ folder with the cloud storage. This works fine for individual files inside a folder.

A change in a file causes that single file to be synced to the cloud storage. With encryption however the sync utility can not differentiate between the different files, it can not look “inside” the container and considers the container as one solid file. So the slightest change to any file in the container causes a full sync of that container. This becomes problematic once you start using larger containers.

Ideally the solution has to have support for cloud storage but this feature-request is not considered as a show stopper though.

No Java

The request was extended with not allowing Java based solutions. There are a number of java based encryption solutions that provide the requested features.

However, using Java in a corporate environment (especially for a ‘security solution’) is a very bad idea. Java has a catastrophic security track record and should be avoided in corporate environments.

Test method, crypto strength and reliability

The timeframe of the request was to short to do a profound check of the implemented cryptographic systems. I also did not verify if the application logic or implementation had vulnerabilities.

The comparison focused on “ease of use for end-users”.

The applications were installed on an up to date Windows 7 and 8, various crypto containers were created and small and large files were copied to and removed from the containers.

Solutions

There are a number of different solutions on the market that position themselves as the perfect replacement for TrueCrypt. Besides the solutions already provided in Microsoft Windows you also have a number of free and non-free solutions.

BitLocker

http://windows.microsoft.com/en-US/windows7/products/features/bitlocker

BitLocker is a Windows integrated drive encryption solution but does not provide container support.

EFS

http://windows.microsoft.com/en-us/windows/what-is-encrypting-file-system

Encrypting File System (EFS) is a feature of Windows that you can use to store information on your hard disk in an encrypted format.

EFS uses the Windows logon credentials to encrypt and decrypt. This means that once you are logged in, whether or not you want access to the encrypted locations, they get decrypted.

The protection of the encrypted files depends on the strength of your password, if you use weak passwords then it’s easy to bypass the protection layer.

There is also no easy way for sharing the encrypted files with other users.

AES Crypt

https://www.aescrypt.com/

“AES Crypt is a file encryption software available on several operating systems that uses the industry standard Advanced Encryption Standard (AES) to easily and securely encrypt files.”

AES Crypt is free and is multi platform but it only allows for single file encryption. The filename of the encrypted file is still visible. This might be considered as an information leak.

AES Crypt supports AES-256.

It is intuitive (right-click and encrypt) to use but the limit to single file encryption only and no filename encryption makes it not suitable for the requested purposes.

Boxcryptor

https://www.boxcryptor.com/

“Boxcryptor is an easy-to-use encryption software optimized for the cloud.”

Boxcryptor is a cross platform solution that is free for personal use (but with limited features). It can use a local account where you do not have shared permission management and you have to manage the security and integrity of the keys yourself. With a “Boxcryptor account” you can grant other users access and the keys are stored remotely.

Boxcryptor support AES-256, AES-192, AES-128 and RSA for keys. The non-free version supports filename encryption.

Although it’s meant to be used on a top of a cloud storage provider, you can also use it to encrypt local containers. On Windows the containers can be assigned a separate drive letter.

The Boxcryptor interface integrates smoothly into windows (tray and explorer). It does not require you to set the size of the container prior to creating the encrypted volume.

Boxcryptor has a company package with LDAP integration, policies and tracking user activities. Especially the later can be important in company environments.

BestCrypt

http://www.jetico.com

“Use BestCrypt Container Encryption to securely store selected files or folders on an active computer, shared workstation or network storage.”

BestCrypt is a cross platform solution that is available for trial for a limited numbers of days. It supports both containers and volumes and also supports integrated swap file encryption. BestCrypt also supports hidden containers. On Windows the containers can be assigned a separate drive letter.

BestCrypt supports 3-DES, CAST, IDEA, RC6, AES, Serpent and others. The key management can be password based and public key based.

The interface is straightforward and quite similar to TrueCrypt. The interface has a couple of interesting extras like a text encoder utility (so you can quickly encode / decode texts, this might be useful if you can not use f.e. GPG to transmit messages), an “anti-keylogger feature” (to verify that your password to unlock the volumes is not captured by malware) and an algorithm benchmark test.

BestCrypt requires you to define the size of the container prior to the creation.

VeraCrypt

https://veracrypt.codeplex.com/

“VeraCrypt is a free disk encryption software brought to you by IDRIX (https://www.idrix.fr) and that is based on TrueCrypt.”

VeraCrypt supports encryption for containers and full system drive encryption and it has all the features you can find in the old TrueCrypt.

VeraCrypt supports AES, Twofish and Serpent and different hashing algorithms.

VeraCrypt requires you to define the size of the container prior to the creation.

The interface of VeraCrypt is almost identical to the interface of the old TrueCrypt.

Source code reviews and crypto strength

There has been a lot of discussion whether TrueCrypt was “truly” open source. You could review the code but there were doubts if the binary was indeed compiled from that same source code. This compilation process has been examined at https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/.

If free available source code is important for you then VeraCrypt (full open source) and BestCrypt (with the development kit) are the best choices.

Having the source code available does not mean that the code has been audited though neither does it mean that people who looked at the code fully understood how the different features worked.

Boxcrypto has not open sourced its code but provides an extensive technical overview at
https://www.boxcryptor.com/en/technical-overview

There’s not a lot of difference in cryptographic strength between the three solutions in their default setup. BestCrypt and VeraCrypt provide more tunable options but the settings of Boxcrypto are acceptable.

Conclusion

The two build-in solutions for Windows, EFS and BitLocker are not a good choice. They either do not cover the needs (BitLocker) are have a questionable security setup (EFS).

AES Crypt is a very simple solution for ad-hoc encryption of individual files but it is to limited for the intended use.

This leaves three possible candidates : Boxcryptor, BestCrypt and VeraCrypt. The latter two mimic the behavior and interface of TrueCrypt. Boxcryptor and Veracrypt have the capability to hide the original filename (I could not find a similar setting in BestCrypt). As far as I could check, only Boxcryptor allows you to have dynamically sized containers. The other two solutions require you to set the size before creating the container.

Do you want to store the encrypted volumes on a cloud storage provider?

Use Boxcrypto. It provides integrated syncing with Dropbox, Google Drive and WebDAV enabled storage. Boxcrypto is not limited to cloud storage solutions only, you can also use it with local containers.

In need of a free solution that mimics TrueCrypt?

Use VeraCrypt. Although BestCrypt provides a set of extra features, there’s no real compatibility with TrueCrypt. The migration path from TrueCrypt to BestCrypt involves opening the old container, copying the files to a new container and closing the container. That can hardly be called “compatibility”.

Boxcrypto

The Boxcrypto solution seems the most flexible solution for having encrypted, shareable containers on Windows. The choice for the Company Package with policies, centralised management, Active Directory support and support for a master key is advised in a corporate environment.

Espionage for OSX

Although the scope of the request was limited to tools that are available on Windows (all proposed solutions are cross platform though) I’d like to draw the attention to a Mac OSX tool called “Espionage“.

Espionage is an encryption tool that also provides plausible deniability for your data. If you run OSX it’s worth checking out.

Part 5 – Overview Best Practices

This is the fifth part in a list of cheatsheets based on the book Network Security: Private Communications in a Public World (2nd Edition).

This post provides an overview of some best practices. The first part, Cryptography Introduction Cheatsheet – part 1, was about cryptography, the second part, Cryptography Introduction Cheatsheet – part 2, about authentication, the third part Cryptography Introduction Cheatsheet – part 3, about standards and the fourth part Cryptography Introduction Cheatsheet – part 4 – Electronic Mail, about electronic mail.

Perfect Forward Security

PFS – Perfect Forward Security is a protocol property that prevents someone who records an encrypted conversation from being able to later decrypt the conversation, even if they gotten hold of both sides cryptographic secrets.

It can be done with a Diffie-Hellman exchange (as in IKE) and have both sides forget the D-H information after the conversation.

The other way of doing it is as in SSL/TLS where one side, Bob, generates a public/private key and the other side, Alice, sends a random number encrypted with the public key.

Change keys periodically

The more examples of ciphertext you see, the more likely it becomes someone will be able to break the encryption and find the key. So when any key has been used on a certain amount of data you should change keys, key rollover.

Multiplexing flows over a single SA

Different conversations should not be multiplexed to use the same security association (SA). Traffic belonging to different service classes should also not be using the same SA. Ideally different SAs should also use different algorithms.

Use different keys in the two directions

This avoids reflection attacks.

Use different secret keys

Use different keys for

• encryption and integrity protection;
• different purposes;
• signing and encryption.

Have both sides contribute to the master key and Don’t let one side determine the key

Attackers have to learn both side’s private key and if either side has a good random number, the result will be a good random number.

Key expansion

Key expansion is the technique of using a small number of random bits as a seed and from it deriving lots of bits of keys.

Others

• Hash in a constant when hashing a password;
• Randomly chosen IVs;
• Use of nonces in protocols;
• Don’t let encrypted data begin with a constant or a predictable value;
• Compress data before encrypting it. Compression has to happen before encryption because compression depends on the data being somewhat predictable;
• Don’t do encryption only, also do integrity protection;
• Avoid weak keys;
• Put checksums at the end of data;
• Design a protocol with forward compatibility;

Part 4 – Electronic Mail

This is the fourth part in a list of cheatsheets based on the book Network Security: Private Communications in a Public World (2nd Edition).

This post is about standards. The first part, Cryptography Introduction Cheatsheet – part 1, was about cryptography, the second part, Cryptography Introduction Cheatsheet – part 2, about authentication and the third part Cryptography Introduction Cheatsheet – part 3, about standards.

Electronic Mail Security

There are two types of mail distribution lists

• The remote exploder method is where a remote site sends the message to its recipients;
• In the local exploder method the sender gets the list of recipients from the remote site.

Mail infrastructure consists of different Message Transfer Agents – MTA that store and forward a message. The path for mail from source to destination might be intermittent.

A list of security services that can be provided for electronic mail are

• privacy Alice wants to send a message to B, she chooses a random secret key S, encrypts the message with S, encrypts S with Bob’s key and then send both the encrypted message and the encrypted S to Bob;
• sourceauthentication can be done with public key technology (signing the message) or secret keys (doing cryptographic computation on the message which results in a MIC or message integrity code or MAC – message authentication code);
• message integrity is -in most cases- already provided by source authentication;
• non-repudiation is provided with public key by signing the message (source authentication). With secret keys we can use a seal provided by a notary-N (Alice sends the message to N and does source authentication with N, then N knows the message came from Alice. N does some computation on the message and Alice’s name which generates the seal on the message);
• a proof of submission can be done by generating a message digest on the message with any other useful information;
• The proof of delivery can be done with a message receipt. Note that this is not a “if and only if”. If the recipient signs before the delivery it can get lost, if the recipient has to sign after delivery he might not furnish a signature at all;
• message flow confidentiality can be established by sending encrypted messages to intermediaries and including the final message as part of the encrypted message;
• anonymity;
• containment;
• audit;
• accounting;
• self destruct;
• message sequence integrity;

There’s on single standard for text representation so sometimes systems have to do transformations (encode) on the message text.

PEM and S/MIME

PEM was developed as a means of adding encryption, source authentication and integrity protection to email. The design of PEM lets you base user keys on secret key or public key technology.

A mail message can contain pieces that have been processed in different ways by PEM. PEM marks a piece that it has processed with a string before and after. PEM can combine these pieces into a message (note that these pieces can also be nested inside one another)

• ordinary, unsecured data;
• integrity-protected unmodified data (called MIC-CLEAR);
• integrity-protected encoded data (called MIC-ONLY);
• encoded encrypted integrity-protected data (called ENCRYPTED).

The long-term key used by PEM is the interchange key (either the public key or the shared secret key). The interchange key is used to encrypt the per-message key.

For the PEM certificate hierarchy, RFC1422 recommends an organization of CAs. The single root CA, IRAP – Internet Policy Registration Authority certifies other CAs called PCA – Policy Certification Authorities. The different policies are

• HA – High assurance, meant as ‘super-secure’;
• DA – Discretionary assurance, doesn’t impose any rules on the orgs to which it grants certificates (other than being the ‘owner’);
• NA – No assurance, no constraints except that it is not allowed to issue two certificates with the same name.

PEM users can issue a CRL-RETRIEVAL-REQUEST to the CRL service to get a list of revoked certificates.

Encryption of a message is done with a randomly chosen per-message key and a initialization vector (IV). Integrity protection is done by calculating a MIC (MD2 or MD5). Users can (usefully) forward a message if public key technology is used.

S/MIME says that its encrypted blobs are binary data so MIME takes care of encoding them. S/MIME supports different public key infrastructures

• S/MIME with Public Certifier (like for example issued by companies as Verisign);
• S/MIME with Organizational Certifier (easy to configure in an internal network, more difficult to have someone external have trust the issuer);
• S/MIME with Certificates from Any Old CA, you first send me your certificate, I store it in my address book and trust it.

PGP – Pretty Good Privacy

PGP is not only for mail, it can do encryption and integrity protection on files. It uses public key cryptography for personal keys. PEM assumes a rigid hierarchy of CAs, PGP assumes anarchy. PGP allows you to specify if the handled file is text or binary. If it’s set to binary then PGP will not canonicalize it. PGP indicates whether what is being signed is a message or a certificate. It includes a file name with every message (specifies the name of the file that was read to produce the PGP object). PGP allows you to choose any name you want (no uniqueness enforced).

A PGP message contains different primitive objects. Every PGP object has a human-readable header and footer. The list of message formats are

• Encrypted message;
• Signed message;
• Encrypted signed message;
• Signed Human-Readable Message;

The key ring stored public keys and information about each key. Each key consists of the name of the human associated with the key (userid), set of certificate signatures you’ve received and the trust information about each of the pieces of information. [publickey|trust|userid|trust|signature|trust|…|signature|trust].

Part 3 – Standards

This is the third part in a list of cheatsheets based on the book Network Security: Private Communications in a Public World (2nd Edition).

This post is about standards. The first part, Cryptography Introduction Cheatsheet – part 1, was about cryptography and the second part, Cryptography Introduction Cheatsheet – part 2, about authentication.

Kerberos V4

Kerberos is a secret key based service for providing authentication in a network. It uses a KDC on a secure node. A login session is the period between logging in and logging out. The KDC shares a master key (secret key) with each principal (user/resource). When Alice informs the KDC that she wants to talk to Bob a session key is created and she is issued a ticket that is encrypted with the key of Bob (so Alice can not read it). The credentials are the ticket to Bob together with the session key. The KDC also sends a TGT – Ticket Granting Ticket. Because of this, the workstation to which Alice authenticates does not need to continue to remember Alice’s password, it can use the TGT to request access from the KDC to other resources. In theory the TGS Ticket Granting Server could be separate but in Kerberos they are the same thing. The KDC database is protected (encrypted) with a KDC master key. Current implementations of Kerberos use DES.

The login process is as follows

1. Alice types account name and password;
2. The workstation contacts the KDC (clear) with the account name;
3. The KDC replies with credentials (a session key and a ticket granting ticket – this is encrypted with the KDC’s master key, not readable for anyone else than the KDC) for the KDC encrypted with Alice’s master key;
4. The workstation converts the typed-in password to a DES key that is then used to decrypt the received credentials;
5. If successful, the master key is forgotten and only the session key and TGT are remembered.

Note that the TGT is double encrypted; once with the KDC master key, then with Alice’s master key. In Kerberos V4 the user was only requested for the password once the credentials were received (minimal time storage in memory, in V5 the user has to type in the password before the request is send). Once the login process is successful and Alice wants to access a remote node (Bob) this happens

1. The workstation sends to the KDC the TGT, the name “Bob” and an authenticator (this is the time of the day encrypted with the session key);
2. The KDC decrypts the TGT and discovers the session (Sa) key and checks the expiration time in the TGT;
3. The KDC constructs a ticket (a newly generated key (Kab), the name “Alice” and an expiration time) encrypted with the key of Bob. This ticket is then send to the workstation together with the name “Bob” and the new key and encrypted with the session key (Sa);
4. The workstation sends the ticket to Bob;
5. Bob decrypts the ticket and discovers the newly generated key (Kab), he also discovers the time via the decrypted authenticator;
6. Bob increments the time of the authenticator, re-encrypts it with Kab and sends it back to Alice.

Because of the use of (time-based) authenticators it is important to keep workstations time synced. To protect against replays Bob should store recently received timestamps.

One single KDC becomes a single point of failure. Therefore multiple KDCs should be set up. One site holds the master key. This site gets all the updates (modify, delete, …) and other sites download periodically from this site. During the download it is import to protect the data from disclosure or modification.

Realms allows the principals in the network to be divided into “groups” so not all participants have to trust each other. In Kerberos V4 each principal consists of a name, an instance and a realm (each part is 40 chars long, case sensitive, null-terminated). In Kerberos V4 it is not possible to get access through a chain of KDCs.

Each key in Kerberos has a version number to facilitate key changes. Resources should remember several versions of their own keys.

Combined privacy and integrity checks is provided in Kerberos with a modified version of CBC, PCBC – Plaintext Cipher Block Chaining.

In Kerberos V4 the network layer address (IPv4) is put in the ticket to prevent impersonation (and interception). But because it is in the ticket and not in the authenticator it also prevents delegation.

In summary

• A ticket is an encrypted piece of information that is given to principal Alice by the KDC and stored by Alice. It is encrypted by the KDC with Bob’s master key. Alice can not read it but can send it to Bob who can decrypt it;
• An authenticator is a piece of information included in a message at the start of the communication between Alice and Bob which proves both participants to prove that they are who they claim to be. It is encrypted with the session key that Alice requested from the KDC.

Kerberos V5

Kerberos V5 uses ASN.1 syntax with BER – Basic Encoding Rules. ASN.1 is a data representation language standardized by ISO. ASN.1 is more flexible but it adds a lot of overhead. In V4 a principal was named by three fields name, instance and realm). In V5 there are two components : realm and name. The name contains a type and a varying number of arbitrary strings.

Delegation of rights is the ability to give someone else access to things you are authorized to access. Kerberos V5 allows delegation by allowing Alice to ask for a TGT with a network address different from hers. In the request Alice can opt for a different network address or no network address (then it can be used from everywhere). The new TGT as such requested by Alice can not be used by Alice but can be passed to Bob. There is also a possibility to limit the rights

• Rather than giving a TGT, Alice provides Bob tickets to specific services (a TGT allows Bob to ask for every service);
• Alice can request a field AUTHORIZATION-DATA be added to the requested ticket or TGT. This field is then interpreted by the application;

Two flags in a TGT involve delegation permission

• forwardable : the TGT can be exchanged for a TGT with a different network layer address;
• proxiable : the TGT can be used to request tickets for use with a different network layer address.

In V4 the maximum ticket lifetime was about 21 hours. In V5 it can be virtually unlimited. This can pose a security risk. Therefore there is the possibility to have renewable tickets where the KDC sets the RENEWABLE flag inside the ticket. A RENEW-TILL specifies the limit. Alice will have to renew the tickets before expiration (maybe with the use of a daemon). Tickets can also be created postdated with a timestamp (set with START-TIME) in the future. Initially the KDC sets the INVALID flag, when the time in START-TIME occurs Alice can present the ticket and then the KDC clears the INVALID flag.

In V5 the KDC keeps track of multiple key versions to facilitate renewable and postdated tickets. The keys are stored as a triple : key, the version number of the key and the version of number of the KDC key to sign this key (because the KDC can also change keys).

In V4 DES was used as the encryption algorithm. V5 can use different algorithms due to its modular design. For integrity checks, in V5 the MACs (message authentication codes or integrity check or checksum) are rsa-md5-des (required), des-mac (required), des-mac-k (required), rsa-md4-des (optional) and rsa-md4-des-k (optional). For encryption and integrity protection you can use des-cbc-crc, des-cbc-md4 and des-cbc-md5.

With different realms in V4 it was needed that the KDC be registered as a principal in each of them. In V5 you can go through a series of realms to authenticate.

In order to protect better against off-line password guessing when requesting a TGT for another user you must supply PREAUTHENTICATION-DATA to prove that you know the master key of that user.

Kerberos V5 allows Alice to choose a different key for multiple conversations and put that in the authenticator.

PKINIT provides a bridge between public key enabled users and servers that only know secret key technology.

The entries in the V5 KDC database consist of

• name of the principal;
• principal’s master key;
• p_kvno principal’s key version number;
• max_life defines maximum lifetime for tickets;
• max_renewable_life maximum lifetime for renewable tickets;
• k_kvno KDCkey version;
• expiration time when the database entry expires;
• mod_date modification date of entry;
• mod_name name of the last modifier;
• some flags indicating KDC policies;
• password expiration defines time when password expires;
• last_pwd_change time when user last changed password;
• last_successtime of last successful user login.

PKI – Public Key Infrastructure

A PKI – Public Key Infrastructure consists of the components necessary to securely distribute public keys.

• certificates;
• a repository for retrieving certificates;
• a method for revoking certificates;
• a method for evaluating a chain of certificates from public keys that are known and trusted in advance (trust anchors) to the target name.

• A certificate is a signed message vouching that a particular name goes with a particular public key;
• The issuer signs a certificate vouching it is for a particular name and key, the subject;
• The verifier (or relying party) evaluates a chain of certificates;
• Anything with a public key is a principal;
• A trust anchor is a public key that the verifier has decided through some means is trusted to sign certificates.

There are different PKI trust models.

• In the monopoly model one organization is chosen to be the single CA for the world. This has problems because there’s not one organization trusted by everyone, a key change would require all software and hardware to reconfigure and how would they certify a remote requester?
• The monopoly model plus registration authorities (RA) is similar except that the single CA chooses other organizations to securely check identities and obtain and vouch for public keys. It is more convenient than the first model to get certified but all the other disadvantages apply;
• In the delegated CA the trust anchor CA can issues certificates to other CAs. Users do not have to go to a single CA;
• The oligarchy model is commonly used in browsers. The products come configured with many trust anchors and a certificate issued by any one of them is accepted. This is even less secure than a monopoly model because instead of one organization at risk (CA) you now have multiple organizations at risk; the trust anchors are trusted by the vendor (product), not by the user; it might be easy to trick a user into adding a bogus trust anchor; there is no practical way to examine the set of trust anchors;
• The anarchy model is used by PGP. Each user is responsible for configuring some trust anchors and anyone can sign certificates for anyone else. Some organizations provide a database where these certificates are stored. This is unworkable on large scale because the database would get unworkable large and it becomes very complicated to entirely trust the chain of trust anchors.

CAs are bound by name constraints were they can only be trusted for certifying a subset of users.

• Top down name constraints is similar to the monopoly model. It is easy to find the path to a name (follow the namespace from the root) but it has the same issues as the monopoly model;
• Bottom up name constraints model is not deployed although Lotus Notes is close. Every organization creates its own PKI and then link to others.

Revocation is necessary when someone realizes their key has been compromised or if someone leaves an organization. A timestamped CRL lists the revoked certificates.

• A Delta CRL is short (often containing no certificates) containing the revoked certificates since the last full CRL was published;
• The First Valid Certificate is a CRL where periodically users with a serial number lower than n have to reissue a new certificate;
• An OLRS – Online Revocation Server is a system that can be queried about the revocation of individual certificates;
• The Good-lists vs Bad lists model envisions a scheme with lists of valid certificates. The list of good certificates is likely larger so this can have a performance impact.

A PKI can be facilitated by a distributed hierarchical database like DNS or X.500. DNS has captured the low end of functionality where efficiency is needed. Names in a certificate are X.509 containing information such as version, serialnumber, signature (the algorithm used to compute the signature on this certificate), issuer, validity, subject (the X.500 name of the entity whose key is being certified), ….

An ACL – Access Control List defines if users have access to a resource. Instead of listing for each resource the users, you can also have a database containing users listing what they are allowed to do. Groups were introduced to make ACLs more scalable. A role concept defines the different privileges a user gets depending on how the user is logged in.

Real Time Communication Security

An application implemented on Layer 3 (IPSEC) causes all applications to be protected without the applications having to be modified. IPsec implementations, IP can tell the application only the IP address it is talking to, no what user is on the other end.

An application implemented on Layer 4 (SSL/TLS, SSH) is implemented as a user process, no change is needed to the operating system. It requires the application to “interface” to SSL and no to TCP. A downside of this implementation is that if malicious data is inserted into the packet stream, as long as it passes the TCP checks, it will get acknowledged by TCP and passed on to SSL. SSL will reject it. If the packet is resend then TCP will think it is a duplicate.

After the cryptographic mutual authentication it remains important to protect the data from disclosure or modification. Next to this the communication should also be protected against session hijack where someone else takes over a session (by forging one side of the communication).

A protocol has PFS – Perfect Forward Secrecy if it is impossible for an intruder to decrypt a conversation between Alice and Bob, even if the entire encrypted session is recorded and the intruder steals the long-term secret of both Alice and Bob. The trick to PFS is to generate a temporary session key that is not derivable from information stored on the nodes and where the session key is forgotten once the session ends. Protocols with PFS also have escrow-foilage which means that even if Alice and Bob are forced to give their key the conversation can not be read. Note that Kerberos does not have PFS.

A denial of service or clogging protection is the use of cookies (not web browser cookies). A stateless cookie (as in f.e. Photuris) is a cookie that is a function of the IP address and a secret known to Bob.

IPsec

An IPsec SA – security association is a cryptographically protected connection. A cryptographic key and other information (identity of other end, sequence number, cryptographic services used) are associated with the SA. An SA is unidirectional, so for a conversation between Alice and Bob there will always be two SAs. An IPsec header, SPI – Security Parameter Index, identifies the SA, allowing Alice to look up the information in her SA database. The SPI value is chosen by Bob. A IPsec Security Policy Database is a database specifying which type of packets should be dropped, forwarded or accepted without IPsec protection, …

IPsec has two modes

• transport mode where IPsec information is added between the header and the remainder of the packet. Most often used end to end. ( [IP header|packet] -> [IP header|IPsec|packet] );
• tunnel mode keeps the original packet and adds a new IP header and IPsec information (ESP or AH) outside. Most often for firewall to firewall or endnode to firewall. ( [IP header|packet] -> [newIPheader|IPsec|IP header|packet] ). It uses a little bit more space because there are now two IP headers. It is essential between two firewalls to preserve the original source and destination address.

An IPsec tunnel can not go through a NAT – Network Address Translation box because the NAT box wants to update the IP addresses inside the encrypted data … and it does not have the key. Even IPsec transport mode has problems because the IP address is included in the TCP/UDP checksums.

The IPv4 header has a protocol field (tcp=6, udp=17, IP=4). IPsec defines two new values: ESP=50 and AH=51. The IPv6 header equivalent field is next header (with the same values as in IPv4).

There are two types of IPsec headers

• AH – Authentication Header providing integrity protection only;
  • next header (1 octet) is the same as the protocol field in IPv4;
  • payload length (1 octet) size of AH header in 32-bit chunks, not counting first 8 octets;
  • 2 unused octets;
  • SPI (4 octets);
  • sequence number (4 octets), has nothing to do with a TCP sequence number but prevents replayed packets in AH;
  • authentication data that provides a cryptographic integrity check on the data.

  Some fields in an IP header get modified by routers etc. so they can not be included in AH integrity check. These fields are type of service, flags, fragment offset, time to live and header checksum.

• ESP – Encapsulating Security Payload providing encryption and / or integrity protection.
  • SPI (4 octets);
  • sequence number (4 octets), has nothing to do with a TCP sequence number but prevents replayed packets in AH;
  • an IV (initialization vector);
  • the (protected data;
  • some padding;
  • padding length (1 octet);
  • next header / protocol type (1 octet);
  • authentication data is the cryptographic integrity check.

Why would you use AH? AH provides integrity protection for some of the fields in the IP header.

IPsec : IKE

IKE is a protocol for doing mutual authentication and establishing a shared secret key to create an IPsec SA. It’s intent is to do mutual authentication using some sort of long term key (pre shared key, public signature-only key or public encryption key) and establish a session key. The specification of IKE is in three pieces

• ISAKMP – Internet Security Association and Key Management Protocol, RFC 2408
• IKE, RFC 2409;
• DOI – Domain of Interpretation, RFC 2407

Photuris was one of the main candidates for this piece of IPsec. It was basically a signed Diffie-Hellman exchange with identity hiding by first doing an anonymous Diffie-Hellman and using an initial stateless cookie. SKIP – Simple Key Management for Internet Protocols was one of the other candidates.

IKE defines two phases

• Phase 1 (known as ISAKMP SA or IKE SA) does mutual authentication and establishes session keys. It is based on identities (names, secrets such as public key pairs or pre-shared secrets). it hase two modes (the exact mode is chosen by Alice)
  • Aggressive mode uses three messages for mutual authentication and session key establishment;
  • Main mode uses six messages and has the ability to hide endpoint identifiers from eavesdroppers and has additional flexibility in negotiating the crypto algorithms.

  The Phase 1 establishes 2 session keys : an integrity key and an encryption key (integrity protecting and encrypting the last of the pase 1 IKE messages and all phase 2 IKE messages).
  IKE Phase 1 supports these protocols

  • Public Signature Keys, Main Mode;
  • Public Signature Keys, Aggressive Mode;
  • Public Encryption Key, Main Mode, Original;
  • Public Encryption Key, Aggressive Mode, Original;
  • Public Encryption Key, Main Mode, Revised;
  • Public Encryption Key, Aggressive Mode, Revised;
  • Shared Secret Key, Main Mode;
  • Shared Secret Key, Aggressive Mode.
• In Phase 2 an ESP or AH SA is established. IPsec allows that each side of a phase 2 SA restricts the traffic sent on that SA (IP address, protocol, type and/or port). It is done by having the phase 2 initiater propose a traffic selector.

Phase 2 IKE (Quick Mode) is a 3-message protocol that negotiates parameters (cryptographic parameters, the SPI, …) for the Phase 2 SA. All messages are encrypted with Phase 1 SA’s encryption key and integrity protected with Phase 1 SA’s integrity key.

ISAKMP/IKE messages have a fixed header and then a sequence of payloads. Similar to IPv6, each payload starts with TYPE OF NEXT PAYLOAD and LENGTH OF THIS PAYLOAD. Some of the different payload types are

• SA – Security Association, this includes the P and T payloads;
• P – Proposal : indicates what “protocol” you’re trying to negotiate (Phase 1 IKE, ESP, AH);
• T – Transform : indicates a complete suite of cryptographic algorithms needed by P. Each P contains a set of Ts;
• … ;

SSL/TLS

SSL/TLS allows two parties to authenticate and establish a session key that is used to cryptographically protect the remainder of the discussion. It is designed to run in a user-level process and runs on top of TCP. A basic overview of the protocol is

1. Alice sends Bob a list of cryptographic algorithms that she supports and sends a random number Ralice;
2. Bob sends Alice his certificate, a random number Rbob and a selection of one of the ciphers;
3. Alice sends to Bob a random number S (pre-master-secret) encrypted with his public key, a hash of the master secret K and the handshake messages;
4. Bob replies with a keyed hash of all the handshake messages, encrypted and integrity protected with his keys. Since the session keys are derived from S he proves he has access to the private key because he needed it to extract S.

Often there’s no mutual authentication (Alice knows she’s talking to Bob but Bob has no clue). SSL/TLS allows session resumption (and so skipping the public key portion of the handshake) if Alice sends a session_id that Bob remembers.

A cypher suite is a complete package (encryption algorithm, key length, integrity checksum algorithm). In SSLv2 Alice decides the suite (Alice sends, Bob replies with what he supports from Alice and then Alice chooses). In SSLv3 Bob makes the choice from the list of Alice.

SSL/TLS runs on TCP so TCP will handle breaking the messages up in packets and reassembling them. SSL/TLS has two layers of chunking which operate somewhat independently

• The unit of cryptographic protection is the record (header + body). There are four record types
  • 20=ChangeCihperSpec (is really part of the handshake). It indicates that all records following this will be protected by the agreed on ciphers;
  • 21=alert , indicating the other side something went wrong (1=warning, 2=fatal);
  • 22=handshake. This record contains handshake messages : ClientHello, ServerHello, ServerHelloDone, ClientKeyExchange, ServerKeyExchange, CertificateRequest, Certificate, CertificateVerify, HandshakeFinished;
  • 23=application data;
• The parts of the handshake are divided into messages (header + body).