secFinalPrep

• Basic Cryptography:

− Private-key encryption (Lectures 1 & 2)

The private key K is shared between Alice and Bob

Alice encrypts a message M into a ciphertext C = EK(M),        then sends C to Bob

Bob, with the same key, decrypts C and recovers M by

 DK(C) = DK(EK(M)) = M

− Public-key encryption (Lecture 3)

The Public Key is what its name suggests - Public. It is made available to everyone via a publicly accessible repository or directory. On the other hand, the Private Key must remain confidential to its respective owner. Because the key pair is mathematically related, whatever is encrypted with a Public Key may only be decrypted by its corresponding Private Key and vice versa.

For example, if Bob wants to send sensitive data to Alice, and wants to be sure that only Alice may be able to read it, he will encrypt the data with Alice's Public Key. Only Alice has access to her corresponding Private Key and as a result is the only person with the capability of decrypting the encrypted data back into its original form.

As only Alice has access to her Private Key, it is possible that only Alice can decrypt the encrypted data. Even if someone else gains access to the encrypted data, it will remain confidential as they should not have access to Alice's Private Key.

− Message authentication, hash function & digital signature (Lectures 3 & 4)

Encryption helps prevent an unauthorized individual from reading a message, but it does not prevent that individual from tampering with the message. An altered message, even if the alteration results in nothing but nonsense, can have real costs. A message authentication code (MAC) helps prevent message tampering. For example, consider the following scenario:

Bob and Alice share a secret key and agree on a MAC function to use.

Bob creates a message and inputs the message and the secret key into a MAC function to retrieve a MAC value.

Bob sends the [unencrypted] message and the MAC value to Alice over a network.

Alice uses the secret key and the message as input to the MAC function. She compares the generated MAC value to the MAC value sent by Bob. If they are the same, the message was not changed in transit.

Hashes

A cryptographic hash function takes an arbitrarily long block of data and returns a fixed-size bit string. Hash functions are typically used when signing data. Because most public key signature operations are computationally intensive, it is typically more efficient to sign (encrypt) a message hash than it is to sign the original message. The following procedure represents a common, albeit simplified, scenario:

Alice creates a key pair, keeps her private key secret and publishes her public key by using a trusted certification authority.

Alice creates a message, hashes it, signs the hash by using her private key, and sends the (unencrypted) message and the signature to Bob.

Bob retrieves Alice's public key and decrypts the signature to retrieve Alice's hash.

Bob hashes the message he received from Alice and compares the hash he computed to the decrypted hash. If the hashes are the same, Bob is fairly certain that the message from Alice has not been altered.

Digital signatures

Digital signatures are the public key equivalent of private key message authentication codes (MACs). Whereas MACs use private keys to enable a message recipient to verify that a message has not been altered during transmission, signatures use a private/public key pair.

Because most public key signature operations are computationally intensive, however, it is typically more efficient to sign (encrypt) a message hash than it is to sign the original message. The sender creates a message hash, signs it, and sends both the signature and the (unencrypted) message. The recipient calculates a hash over the message, decrypts the signature, and compares the decrypted signature to the hash value. If they match, the recipient can be fairly certain that the message did, in fact, come from the sender and was not altered during transmission.

Signing ensures only that the original message was not altered and, by using the sender's public key, that the message hash was signed by someone with access to the private key.

− Public-key infrastructure (PKI) (Lecture 4)

A PKI is based on certificates. A certificate is a digitally signed statement containing a public key and the name of the subject. There can be multiple types of names in the certificate by which the subject is known, such as a directory name, e-mail name, and Domain Name Service (DNS) name. By signing the certificate, the certification authority verifies that the private key associated with the public key in the certificate is in the possession of the subject named in the certificate.

This is how PKI is normally implemented today:

Bob creates a pair of keys

Bob brings his ID & his public key to the RA to request a certificate

The RA verifies Bob’s ID and requests the certificate from the CA

The CA creates & signs Bob’s certificate, and posts Bob’s certificate in the directory.

To look up Bob’s public key, Alice would

Get Bob’s certificate from the directory

Verify that the certificate is valid (i.e. has not expired and is not on the CRL)

Verify that the CA who issued and signed the certificate is trustworthy

Verify subject’s identity on the certificate

E.g. company name & URL

Verify that the CA’s digital signature is valid

Take the public key on the certificate if all is fine

Hw2 pki

In order to secure the protocol against active adversaries if a secure PKI is applied, Bob generates a pair of keys and sends RA to request certificate. RA verifies Bob’s private key and request the certificate from the CA the CA generates the Bob’s certificate and posts his certificate in the directory. Alice receives Bob’s certificate from the directory and verifies and guarantees that the Bob’s public key is valid, so Alice trusts that Bob is protected by trusted CA (VeriSign) then Alice encrypts the message with her private key along with the certificate. In this process Eve cannot intercepts the in between because Alice’s and Bob’s both public keys contained within their personal digital certificates which have been digitally signed by the VeriSign. Now Bob decrypts the message with his secret key. This’s how PKI secures the protocol against adversaries.

− Authentication – digital signature (Lecture 5)

An entity is identified by its public verification key

For Alice to authenticate herself to Bob, Alice

Signs a message “Hello Bob, I am Alice” with her (private) signing key.

Only Alice can produce her signature & the signature unforgeable if the underlying signature scheme is secure

Sends the message and her signature to Bob

Bob verifies Alice’s signature using her public verification key

-Authentication – by certificates

The certificate binds the entity’s information with its identity

E.g. www.bankofamerica.com is the URL of the Website of Bank Of America Corporation

Also contains the entity’s public key

The CA digitally signs the certificate

The CA’s signature is attached to the certificate

− Challenges (Lecture 6)

Threats: A problem deemed infeasible for now may become feasible in the future due to advances in algorithms & technology.

-RSA Factoring Challenge:

Quantum Computers: If quantum computers become available, then the factoring problem can be solved easily.

-An Ultimate Goal:

Achieve provable security

against any future advances,

given only the current state-of-the-art.

• Internet & Web Security:

− Email security (Lecture 6)

it is the system that supports Public Key Encryption. Simply put, you need a central repository for all the Public keys that have been created. If you want to send an email to someone using PKE, you need to use the PKI. This means going to a Public Key Server that holds all the public keys.

Paul and Betty

When Paul wants to send an email to Betty, he goes to the closest Public Key Server, and looks up Betty's public key. He encrypts the message and sends it on to Betty. Once Betty receives the message, she decrypts the message using her private key.

To think of it another way, the public key is an encryption-only key that everyone can use to make any message secret - but can never be used to reveal the contents of a message. While the private key is a decryption-only key that only one person is able to use, because only he/she owns that key. It is the perfect solution.

1.     Your computer makes a secure connection with your Internet Service Provider (ISP) via SSL. Your computer passes on the message that has been prepared.

2.     The ISP looks at the address that it needs to send the message to. Because the ISP knows that it needs to use Private Key Encryption (PKE) it goes to the Public Key Server and asks for the Public Key for the intended recipient.

3.     The Public Key Server hands the public key over to your ISP.

4.     Your ISP takes your friend's public key and encrypts your email message and then sends it to your friend's ISP. 

5.     Your friend's ISP takes out the recipient's private key and decrypts the message and sends it on to your friend.

− Secure Socket Layer (SSL) How It Works (Lecture 7)

1. Browser connects to a web server (website) secured with SSL (https). Browser requests that the server identify itself.
2. Server sends a copy of its SSL Certificate, including the server’s public key.
3. Browser checks the certificate root against a list of trusted CAs and that the certificate is unexpired, unrevoked, and that its common name is valid for the website that it is connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key using the server’s public key.
4. Server decrypts the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session.
5. Server and Browser now encrypt all transmitted data with the session key.

Why Do I Need SSL?

One of the most important components of online business is creating a trusted environment where potential customers feel confident in making purchases. Browsers give visual cues, such as a lock icon or a green bar, to help visitors know when their connection is secured.

If your site collects credit card information you are required by the Payment Card Industry (PCI) to have an SSL Certificate. If your site has a login section or sends/receives other private information (street address, phone number, health records, etc.), you should use SSL Certificates to protect that data.

Your customers want to know that you value their security and are serious about protecting their information. More and more customers are becoming savvy online shoppers and reward the brands that they trust with increased business.

− Web authentication by cookies (Lecture 7)

Let's say I visit my favorite forum. It logs me in and appends my session ID to the URL in every request. I find a particularly interesting topic, and copy & paste the URL into an instant message to my friend.

Unless the application has taken steps to ensure that there's some form of validation on the session ID, the friend that clicked that link may inherit my session, and then would be able to do anything I can do, as me.

By storing session identifiers in cookies, you completely eliminate the link sharing problem.

There's a variation on this theme called session fixation, which involves an intentional sharing of a session identifier for malicious purposes.

• System Security:

− Access Control (Lecture 9)

Limit access to data and resources to authorized users only

− Confinement/Isolation (Lecture 9)

− Malware and Intrusion Detection (Lecture 10)