CIS2750 - Securing Information Systems


Chapter 7, Industrial Espionage in Cyberspace; Chapter 8, Encryption

Objectives:

Chapter 7 focuses on stealing information from a company, a competitor, or an authority with approval rights for contracts. Objectives important to this lesson:

  1. Understanding industrial espionage
  2. Techniques of industrial espionage
  3. Knowing something about spyware
  4. Defending your systems from these attacks
Concepts:
Chapter 7

This chapter talks about topics the text has already introduced in the context of stealing from a company for a business advantage. The text points out that businesses typically cannot run if critical staff do not understand and use the secret information of those businesses. This is why nondisclosure agreements exist. There will always be on-boarding and off-boarding of staff. A standard procedure during each of those employment phases is to introduce and to renew the agreement required of all staff not to disclose trade secrets pertaining to that business, neither while employed by the business nor after leaving that employment. That means the business gets to sue staff and former staff who reveal secrets.

We should note why secrets exist. A company may choose not to copyright a process because doing so makes it a matter of public record. Anyone can pay to look up a copyright. The Coca-Cola company, for example, keeps the recipe for Coke a trade secret that is known to only a few employees at a time. This has been a successful method for them since they started making Coke. Several formulae have been published, each claiming to be the one used by Coca-Cola, but there is doubt about each. How does this relate to IT staff? IT staff are frequently aware of manufacturing processes for hardware, features for software, bugs that are not yet public, and other company secrets that could be sold to a competitor. A person who shares this sort of information with people who are not supposed to know it is guilty of breaking any non-disclosure agreement (NDA) they had to sign to get access to the information.

The examples given in the text show us that there can be advantages in secrets that are old or new, research that has produced a product or is still under way, and anything else a company feels is important to their organization. The advantage, the mystique, the monetary value of being the only producer of "product x" disappears when the secret is stolen.and leveraged. That is the bottom line for secrets versus copyrights. You copyright something that the competition could reverse engineer. You keep something a secret that they can't. That last part is important. Does the secret enable a competitor to outperform the original owner, or does it hold the most value for the company it was stolen from? That leads to a decision that has to be made by the spy. Do we sell or ransom the secret? There is a legend that someone once stole the formula for Coca-Cola, and offered it to Pepsi. According to the story, Pepsi called the police. Their reasoning was that it only held value for the Coca-Cola Company. Pepsi did not want to know.


Sometimes, the good guys all win.

When a spy wants to get a secret form a company, a national agency, or any other source, the most logical thing to do is to social engineer an unhappy employee. Buying a stolen bit of information from someone who does not feel appreciated may seem like good business, but it is generally illegal, and the penalties can be harsh, to say nothing of the loss of trust and esteem that the company employing the spy may suffer when the truth comes out.

The chapter moves on to a long bullet list of precautions that may help prevent the loss of secrets. You should review this list. The author promises to discuss more in chapter 9.

Chapter 8, Encryption

Objectives:
  1. Encryption
  2. Modem encryption
  3. Choosing effective encryption
Concepts:

The text has already discussed encryption. This chapter discusses some specific aspects of it. Most books cover similar topics.

A classic introduction to encryption is the cipher used by Julius Caesar. It will be helpful first to define a cipher as a substitution of characters. In the example in the text, each letter in the original message (called cleartext or plaintext) is changed to another character by a specific algorithm (method), resulting in an encrypted message that displays in ciphertext. The Caesar cipher is easy to break, since the same ciphertext letter is substituted each time the same plaintext letter occurs in the message. The cipher is even more vulnerable due to its simple algorithm: add three to each plaintext letter, wrap to front of alphabet as needed (for x, y, and z). It would be harder to break if a random substitution of letters had been used. Ciphers have evolved a good bit, as we will see.

Messages can also be scrambled by steganography. (covered or protected writing) The text briefly reviews a few methods of doing this: hiding a message in unused parts of a file, hiding it in metadata, hiding it where the uninformed would not look, and hiding it in images.

There are five classic kinds of security that cryptography might provide.Not all kinds of cryptography provide all five features. (Some kinds may provide only one.)

  • confidentiality - only those with the decryption algorithm can read it
  • integrity - the message is protected from changes (unless a man in the middle has the encryption algorithm)
  • availability - anyone with the decryption algorithm can read it
  • authenticity - a secure algorithm proves the message was sent by a trusted party
  • non-repudiation - the encryption may prove who did something and when it was done
Hashing

The text continues with a general discussion of hashing, which then branches into specific types. Hashing is defined as creating a unique encrypted result from a data set. The encrypted result is called a hash, a signature, or a digest, all of which mean the same thing. The hash should not resemble the plaintext in appearance or in length. Note that the text also refers to this method as a one-way hash, which means that the hash resulting from the algorithm is not meant to be decrypted. The reason for this becomes clear in the example of its use with an ATM card.

Assume you have an ATM card that is assigned a Personal ID Number (PIN). The card provider used a hash algorithm to create a hash from your PIN which is stored on the card on a magnetic stripe. Sounds less than secure, right? When the card is used, it is inserted into a slot on a machine, and the machine asks for the PIN. The user is expected to enter the PIN, which the machine uses to create a hash, which is then compared to the hash stored on the card. The user is not allowed to use the card if the two hashes do not match.

This makes the use of the ATM card an example of two level security. The card alone is not enough. The user must provide the PIN (something you know) which is used by the machine to create a hash, which is compared to the hash on the card (something you have). Of course, the system breaks down if the hash algorithm becomes known to hackers. Feel like changing your PIN now?

Four characteristics of a secure hashing algorithm:

  • the hash has a fixed size regardless of the size of the cleartext
  • different sets of data will always result in different hashes
  • it is impossible to create a data set that will result in a specific defined hash (This one worries me.)
  • the hash algorithm cannot be reversed to decrypt the original input (This one worries me, too.)

Hash algorithms are typically used to encrypt passwords when users log in to networks. Like the ATM example, the password is never stored in plaintext, only in hash form. The system creates a hash from the password the user enters, and this is compared to the hash for that user ID in the password file. This brings us to the concept that the only security feature provided by hashing: integrity. The other features are defeated by the fact that the hash cannot be decrypted, and the fact that another user may use a stolen password (or PIN).

Message Digest (MD) Hashing

The text discusses three versions of this hashing algorithm. The short story is that none of them are recommended as being secure any longer. They have all been hacked.

  • Message Digest 2 (MD2) - a 16 bit (processor size) algorithm from 1989; creates a hash that is 128 bits long. Messages are processed as 128 bit sections. If a message is not a multiple of 128 bits, the last section is padded with characters to make 128 bits. A 128 bit (16 byte) checksum is added to the message, padded or not, before hashing. Considered too slow to use now.
  • Message Digest 4 (MD4) - a 32 bit (processor size) algorithm from 1990; creates a hash that is 128 bits long. Messages are processed as 512 bit sections. The text notes that this algorithm can create collisions (identical hashes).
  • Message Digest 5 (MD5) - a 32 bit (processor size) algorithm from 1991; uses 4 rotating 32 bit variables; cracked around the turn of the century

Secure Hash Algorithm (SHA)

SHA has two major types, but the second one has four subtypes. It was created by the National Security Agency and the National Institute of Standards and Technology.

  • SHA-1 - the text says this works like MD4, but creates a hash that is 160 bits long. Wikipedia says it is like MD5. It should not be considered secure.
  • SHA-2 has four subtypes, whose names indicate the length of their resulting hashes:
    • SHA-224
    • SHA-256
    • SHA-384
    • SHA-512
  • SHA-3 was released in 2015, and it may still be secure

Password Hashes

As previously discussed, local or domain passwords entered on a computer running Windows are converted by a hash program and compared to a stored hashed version of the user's current password. This is called a cached credential. The text discusses the two versions used in common versions of Windows: LM hash and NTLM hash. We learn that LM hash is not considered a "real" hash because its result is cryptographic (character substitution) instead of numeric (hexadecimal digits). It was used in versions of Windows before Windows NT. NTLM is used in later versions, but we have already been informed that passwords shorter than 14 characters are stored both ways.

Linux systems may use an MD5 hash. The text says that Apple OS X systems use SHA-1, but use NTLM as well if Windows sharing is implemented. This post indicates that OS X is using SHA-512 instead.

Tom discusses it in this video:


In case you don't like Tom, try Josh:


Symmetric Cryptographic Algorithms

Unlike hashes, cryptographic algorithms are typically meant to be used for encryption and decryption. The methods in this group use the same key to encrypt and to decrypt, which is why they are called symmetric. They are also called private key algorithms because the key must remain private to the users of the system or there is no security. (This seems like an obvious point, but we will consider another system where it is not true.)

The text divides symmetric algorithms into two groups. Stream ciphers encrypt one character at a time (from the flowing stream of data). Block ciphers divide the message into blocks of a specific size, then encrypt each block as a unit. The text discusses some methods used by stream ciphers:

  • substitution - each character in the plaintext may be changed to a specific character in the ciphertext, or the cipher may rotate between several cipher algorithms, allowing each character in the plaintext to have several ciphertext representations
  • transposition - the plaintext is reordered based on a key, then the reordered text may be processed against the plaintext in an XOR operation to create the final ciphertext; the text mentions that the reordered text may be processed against a One Time Pad (a random key string)

These are just examples, of course. Three symmetric algorithms to be aware of:

  • DES - Data Encryption Standard
  • 3DES - Triple Data Encryption Standard
  • AES - Advanced Encryption Standard
Asymmetric Cryptographic Algorithms

It should be obvious that asymmetric (not symmetric) algorithms will use different keys. These algorithms are also called public key cryptography. This name does not describe the method well. A person must have two keys in this system, a public key and a private key. They are created so that whatever is encrypted with one must be decrypted with the other. The owner of the keys gives the public key to anyone who wants it, but keeps the private key safe from anyone else.

This is how SSL encryption on a web site works. I connect to a vendor's web site. I obtain the vendor's public key by making the secure connection. My browser encrypts my credit card data with the public key and sends the ciphertext to the vendor. If the vendor's private key is secure, the vendor is the only one who can decrypt the data sent through the public key. In this way, a key is made available to anyone who wants it, but using it makes the data unintelligible to everyone who does not have the private key.

The author describes a process to use a private key to make a digital signature. Note that the user's private key stays in his possession during this transaction, which makes use of the fact that data encrypted with the private key can be decrypted with the public key. This does not make that data secure, but it does prove that the data stream was encrypted with the matching key.

Cryptography on Files and Disks

These are some systems that can be used to encrypt files.

Pretty Good Privacy (PGP)

Although the heading is about PGP, a commercial product, the discussion is also about GPG (Gnu Privacy Guard), which is an Open Source product. The two products are typically compatible.

Everyone who uses PGP will have a public key that is freely available, a private key that remains secure, and everyone can generate new keys as needed if they want to start a new symmetric system.

  1. When I want to send a message to you, I generate a new symmetric key for that message.
  2. I encrypt the message with the symmetric key.
  3. I encrypt the symmetric key with your public key.
  4. I send the encrypted message and the encrypted key to you.
  5. You are the only person who can decrypt the encrypted key, by using your private key.
  6. You then use the decrypted symmetric key to decrypt the message.

In this way, PGP (and GPG) can use both symmetric and asymmetric keys. It's more tedious than just exchanging public keys, but it is more secure.

Microsoft Windows Encrypting File System (EFS)

This file encryption system is transparent to the user who turns it on for a folder or file on his/her system. Note the bullets on page 387 that list features and concerns for this system.

Windows BitLocker

This is a total disk encryption system that is available on some (not all) versions of Windows Vista and Windows 7. It encrypts an entire hard drive, which makes the system more secure against theft. The drive becomes accessible when a user authorized for the device logs in. The drive remains encrypted, but a decryption key is loaded into RAM, making the system transparent to an authorized user.

Note the potential vulnerability in BitLocker mentioned on page 387. First, a laptop encrypted in this way is vulnerable if the attacker gains access while a user is logged in. Second, the device may be accessible if an attacker can harvest the decryption key while the device is in sleep or hibernation (not locked) mode. Advice? Don't walk away from that laptop without locking it or turning it off. Hibernation and sleep modes rarely work well to begin with, so don't use them.

Trusted Platform Module (TPM)

This is a hardware technology that supports hard drive encryption. It features a real random number generator in a chip that is also used for encryption and decryption.

Let's return to the topic of digital certificates. As discussed above, it can be based on the public key system, but it has a problem. Consider the discussion in the text of the way it should work: If you and I both have public and private keys, I can encrypt something with my private key that you can decrypt with my public key. Anyone else could decrypt it as well, but this step proves that the encrypted form came from me, or at least from the person whose public key you have.

As an example, I can send a message to you encrypted with your public key (which only you can decrypt) along with a hash made from the message and encrypted with my private key. The encryption of the hash proves that it came from me: you can decrypt it with my public key. The hash itself will match a hash you can make from the decrypted message, proving that it has not changed. This is a secure system as long as our private keys remain private, and our public keys are not available except by a secure method. As the book explains, the system fails if you think you have my public key, but you really have the key of an impostor who sent the message in the first place. In other words, you know that the message is unchanged since it left the person who sent it, but how can you be sure that it came from the person you think it came from? How do you know my public key is really mine?

You need to get my public key from a trusted source, like Verisign, which is now affiliated with Symantec/Norton. If I register my public key with a trusted source (typically a certificate authority), or have them create it in the first place, they provide me with a copy of the key that is endorsed by them, which makes it a digital certificate. When I send this certificate to someone, they can verify that it is from an authority that can be trusted. Note the properties of a digital certificate:

  • name or alias of the public key owner
  • public key
  • name of the certificate issuer
  • digital signature of the issuer
  • serial number of the certificate
  • expiration date of the certificate (technically, not of the key, but they may be the same)

This leads us to an industry that supports verified identities by the use of digital certificates. Some terms associated with it:

  • certificate authority (CA) - an agency that issues digital certificates; the CA may create key pairs for users or accept them from users who create them; the CA is responsible for verifying the identity of the key owner; organizations with the proper software can act as their own internal CA
  • registration authority (RA) - an entity that takes on some of the tasks of a CA and operates on their behalf
  • certificate revocation list (CRL) - a list of certificates that are no longer valid for various reasons
  • certificate repository (CR) - a public directory of valid certificates; may contain invalid certificates as well or may link to a CRL

The text moves on to discuss different types of digital certificates.

  • personal digital certificates - for individuals to use as needed
  • server digital certificates - for web servers, mail servers, and other type servers to confirm identity of the operator; also used by servers to confirm secure SSL sessions
  • software publisher digital certificates - to confirm data integrity of published software

The certificates described so far have been single-sided, which means they only confirm identity. Dual-sided certificates are actually two certificates: one to confirm identity (signing certificate), and the other to confirm encryption (encryption certificate).

It wouldn't be a security function if someone didn't feel the need to specify a format. Certificates are meant to comply with the X.509 format created by the International Telecommunications Union (ITU).

Public Key Infrastructure

The Public Key Infrastructure is the system (or a specific system) that includes all the concepts listed so far in this chapter. The text discusses three aspects of it: standards, trust models, and key management.

Standards

There are many copies of standards available on the Internet, such as this version at Wikipedia.  These standards actually belong to the RSA Data Security company, but they are "widely accepted".

Managing PKI

More acronyms to recognize.

  • Certificate Policy (CP) - a set of rules that dictate what the CAs, RAs, and other entities must do to operate
  • Certificate Practice Statement (CPS) - if a CP is a set of rules, a CPS is a set of procedures for implementing those rules; the CPS states how entities request and perform services
  • Certificate Life Cycle - certificates should have a planned creation and removal process, so this concept addresses four life events for a certificate:
    • creation - includes the procedures to follow to verify identity, grant and issue a certificate, and publish a certificate
    • suspension - when a certificate should go out of use temporarily, the suspension process is used
    • revocation - when a certificate is found to be invalid because it has been compromised, the owner is out of business, or for other reasons, the certificate is revoked and move to the CRL
    • expiration - the normal end of a certificate's life; one might wonder if this is to sell the owner another one, but it is also sensible to end certificates regularly in case they have neither been suspended nor revoked but should have been and the CA knew nothing about it