Cryptography

Coursework

Block Ciphers A block cipher is a method of encrypting text (to produce ciphertext) in which a cryptographic key and algorithm are applied to a block of data (for example, 64 contiguous bits) at once as a group rather than to one bit at a time.
We are developing a new network and have modern up-to-date hardware that can easily handle larger non-legacy key sizes. Processors on all servers and the corporate data NAS implement AES-NI (Intel, 2019). All storage with the exception of tapes is encrypted using the XTS mode in lieu of CBC as XTS provides superior data protection for sector-by-sector encryption (Kingston Technology, 2019). GCM cipher mode is preferred over CBC for TLS per NIST 800-38D (Dworkin, 2007). Desktops and laptops all support Microsoft Bitlocker or Apple FileVault using AES-128-XTS. TLS encrypted public access to web services use TLS v1.2 minimum and support v1.3 (McKay & Cooper, 2018). Layer 2 LAN communication within #10 is sent back through #19 to the Inner Firewall for inspection. No direct intra-zone peer to peer communication is allowed. IBM LTO only supports DES and 3DES in CBC mode and therefore we utilize those encryption selections (Haeusser, Barney, & Colving, 2009)

Hash Functions A hash function is simply a function that takes in input value, and from that input creates an output value deterministic of the input value. For any x input value, you will always receive the same y output value whenever the hash function is run. In this way, every input has a determined output.
​Integrity Protection is assured through the use of one-way hash functions. "Hash functions have an enormous range of applications in cryptography and computer security. Almost every Internet protocol uses them to process keys, chain a sequence of events together, or authenticate events... They are probably the single most useful tool in a cryptographer's toolbox" (Schneier, 2000) Hash functions take an arbitrarily long message and generate a fixed-size unique output that is derived from the content of the message (Chapple, Stewart, & Gibson, 2018). We will only consider secure hash functions specified in FIPS 180-4 v2015 (NIST Information Technology Laboratory, 2015). Where possible, we will utilize a SHA-2 family hash function with a 256-bit output on all 32-bit components and 512-bit output on all 64-bit components. This choice meets our minimum 128-bit security level while providing the most efficient use of CPU architecture and block size. This consistency in hash function and size choice has the additional benefit of improved portability when we migrate to SHA-3 in the future.

Message Authentication Codes and Secure Channels

Authentication for our network traffic and data is performed using Message Authentication Codes (MAC). MACs don't protect privacy, but they ensure authentication and integrity (Schneier, 2000). Our stated minimum security level is 128 bits and so we will use HMAC-SHA-256 for all components where message authentication is required and under our control (NIST, 2008). For components or protocols where we cannot specify the MAC we will utilize the highest security level offered by the manufacturer of the device or protocol implementation.

Key Distribution Protocols In symmetric key cryptography, both parties must possess a secret key which they must exchange prior to using any encryption. Distribution of secret keys has been problematic until recently, because it involved face-to-face meeting, use of a trusted courier, or sending the key through an existing encryption channel. The first two are often impractical and always unsafe, while the third depends on the security of a previous key exchange.
Key distribution on our network is performed using the RSA public-key cryptosystem. Diffie-Hellman is avoided due to its lack of protection for a man-in-the-middle attack (Ferguson, Schneier, & Kohno, 2010, p. 184). Some components require manual symmetric key entry by Information Technology personnel and are marked in our chart with "Physical Distribution" as the distribution method. All TLS v1.2 traffic uses AES-128-GCM for encryption and HMAC-SHA-256 for message authentication. The symmetric keys needed for encryption and message authentication are generated during the TLS connection. New keys will be generated every time, but we use Key 2 to represent the keys. See "Client Encryption Keys Calculation" (Driscoll, 2018). Changes in algorithm require unique keys. This is why we have additional keys for the two types of NAS encryption, Bitlocker, Tape Drives, and Wireless Access Point. We use separate certificates for external access, provider access, vpn access and internal services. This necessitates four separate RSA public/private keys.

Key Management "The proper management of cryptographic keys is essential to the effective use of cryptography for security" (Barker, 2016, p. iii). Kerberos is a network authentication protocol developed and made freely available by MIT which is designed to solve the problem of proving identity and exchanging keys over an insecure network using strong cryptography (MIT, 2019). The team developing the Kerberos protocol created a system to prove a shared secret (like a password) between a client and an authentication server without sending the unencrypted secret over the network (Tung, 2007). This novel approach allowed the designers to come up with a key distribution system whereby cryptographic keys could be requested and utilized by a client without the client knowing the contents of the key. Key distribution is performed by a Key Distribution Center (KDC) which is typically, but not required to be, implemented as part of a domain controller. "In 1993, Microsoft decided to adopt Kerberos as a primary authentication mechanism within its products, and in 1999 released a fully integrated version of Kerberos with Windows Server 2000" (MIT Kerberos Consortium, 2008, p. 44).

Public Key Infrastructure "The comprehensive system required to provide public-key encryption and digital signature services is known as a public-key infrastructure. The purpose of a public-key infrastructure is to manage keys and certificates" (Entrust Datacard, n.d.) "At its core PKI is all about certificates, how they are created, what information they contain, how they are used, the level of trust you put into them, what happens when they are lost and the simplicity of using them" (Ogenstad, 2010).
A certificate is a document (electronic file) that contains information much like a traditional physical paper certificate (IT Free Training, 2013). This information includes who issued the certificate, who the certificate is issued to, optional organization information as well as an expiry date. Unlike a paper certificate, the digital certificate also contains a public key, algorithm and key size information, as well as the issuer's digital signature. The digital signature proves the certificate came from a trusted source, has not been altered, and is not a fake (IT Free Training, 2013).
The Certificate Authority or CA is the service or provider who is responsible for issuing and revoking certificates (Ogenstad, 2010). "The CA has a public/private key pair (e.g., an RSA key pair) and publishes the public key" distributing it throughout the private network or public Internet as needed (Ferguson, Schneier, & Kohno, 2010). To join the PKI a client generates a public/private keypair and gets the public key signed by the CA private key.
The way the signature guarantees the validity of the certificate is quite clever. The CA hashes the certificate generating a hexadecimal number and then encrypts the hash with their private key. This allows anyone with access to the CA public key to decrypt the signature and verify that it is valid by hashing the certificate themselves and then comparing the values.

Reflection