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:
Understanding industrial espionage
Techniques of industrial espionage
Knowing something about spyware
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:
Encryption
Modem encryption
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.
When I want to send a message to you,
I generate a new symmetric key for that
message.
I encrypt the message with
the symmetric key.
I encrypt the symmetric
key with your public key.
I send the encrypted message and the
encrypted key to you.
You are the only person who can decrypt the
encrypted key, by using your private
key.
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
