0% found this document useful (0 votes)
4 views

CS 340 Lecture 16 Authentication

The lecture discusses the importance of authentication in computer networking, particularly in the context of preventing man-in-the-middle (MITM) attacks. It explains how digital signatures and Public Key Infrastructure (PKI) can be used to verify identities and ensure the integrity of communications. Additionally, it highlights the risks associated with root certificates and the need for certificate revocation lists to maintain security.

Uploaded by

aboubakranas0
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

CS 340 Lecture 16 Authentication

The lecture discusses the importance of authentication in computer networking, particularly in the context of preventing man-in-the-middle (MITM) attacks. It explains how digital signatures and Public Key Infrastructure (PKI) can be used to verify identities and ensure the integrity of communications. Additionally, it highlights the risks associated with root certificates and the need for certificate revocation lists to maintain security.

Uploaded by

aboubakranas0
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 43

1

CS-340 Introduction to
Computer Networking
Lecture 16: Authentication
Steve Tarzia
2
Last Lecture: Encryption and Anonymity
• Network security goals are:
• Confidentiality, Reliability, Integrity, Authentication & Anonymity
• Routers and other participants on the network cannot be trusted.
• AES is a the standard symmetric-key encryption algorithm. Must
somehow establish a shared session key, used by both parties.
• Public Key cryptography (RSA, ECC) uses a pair of related keys.
• Public key is openly advertised and is used for encryption
• Private key is secret and is used for decryption.
• Onion-routing/mix networks create routing overlays on the Internet.
• Sender encrypts data many times. Relays decrypt one layer each.
• This enables anonymous web browsing and even anonymous services.
3
Authentication definition
• Verifying the identity of the person/host I’m communicating with.

Why does confidentiality (keeping messages secret) require STOP


and
authentication? THINK

• There are many ways in which Internet messages can be read by


untrusted 3rd parties.
• In order to start encryption, we have to verify that we are exchanging
public keys with the intended party, not a “man in the middle.”
4
Man-in-the-middle (MITM) attack
• A major flaw remains in this communication scheme.
• We cannot be sure that the machine we contacted is actually who we
intended to contact – messages may not be authentic.
• A malicious intermediate router may establish two different encrypted
sessions between the communicating parties and relay messages.
• MITM advertises a false public key (its own) to the sender
• MITM is then able to decrypt sender’s message and re-encrypt message with
the receiver’s true key before delivery.
• Messages can be viewed and altered before delivery.
• MITM can violate confidentiality, integrity, and authentication.
A
MITM Attack An evil router

5
(🔑A,🔓A) (🔑
G,🔓G)
(🔑M,🔓M)

Here’s my public key 🔓A


Let’s talk securely!

Here’s my public
key🔓M
Let’s talk securely!

OK. Here’s my
public key 🔓G

OK. Here’s my public key 🔓M

4903c2…
“I feel pretty”
5933c0…

11290a…
“Do you?
Rewrite to
“So do I!”
0943e2…

MITM can read and alter messages!


6
How to avoid MITM attacks?
• Simple, but impractical, solution is to avoid public-key cryptography.
Instead just use symmetric encryption with pre-shared key.
• To use public key cryptography, we must be sure that the public key we
receive really belongs to the endpoint, and not some MITM.
• If so, we can be assured that only the endpoint has the private key.
• Real-world solutions involve using digital signatures to verify public
keys (certificates).
7
Why digital signatures?
• Want to produce a public document (not encrypted) that:
• Makes some claim (or has a message, in general).
• Anyone can verify the author of the document/message.
• In other words, it’s not possible that someone else forged the document.

• The existence of the signature on the document proves something.


• We don’t care who gave us a copy.
• Unlike real-world ink signatures, an attacker cannot copy a signature from one
document to another. Signature is somehow unique to the document.

• Notice this is a case when we need authentication and integrity, but


not confidentiality.
8
Digital Signatures

• A digital signature is a short bit-sequence generated from a digital


document and a private key, with the following properties:

• Like a hash function, it always produces the same result (for given data).
• It produces different results for different documents and keys.
• The document cannot be signed without a private key.
• The signature can be verified using only the corresponding public key.

• Closely related to public key encryption: can use the same RSA keys.
• Changing a signed document will make the former signature invalid.
9

Meg
Signing: The signer
likes
beets
Meg
likes uses the RSA private
beets
to encrypt the message
hash, creating a
signature.
🔑 Meg
likes Verification: Anyone
beets
Name of signer, looking at the
Public key 🔓
certificate can use the
public key to try to
Certificate 🔓 decrypt the signature.
If this leads to the true
message hash, then the
Meg signature must have
likes
been generated using
beets
If hashes are equal, the the true private key.
signature is valid
For confidentiality, we

10
encrypt with public
Meg keys, but here we use Signing:
The signer
likes
beets
private key. Why?
STOP
Meg
likes uses the
RSA private
and
THINK
beets
to encrypt
the message
hash,
creating a
signature.
🔑 Meg
likes
Verification: Anyone
beets
Name of signer, looking at
the
Public key 🔓

certificate can use the


public key
to try to
Certificate 🔓 decrypt
the signature.
If this
leads to the true
message
hash, then the
Meg signature
must have
likes
been
generated using
beets
If hashes are equal, the the true
private key.
signature is valid
11
The meaning of signatures
• If I download a document with a statement (“Meg likes beets”) and
that document contains a valid digital signature for public key 🔓M,
I know that:
• Someone with access to the private key 🔑M saw the document and chose to
run the signing algorithm to compute the corresponding signature.
• We know that only someone holding the private key would have any
reasonable chance of computing the correct signature for that ⟨document,
public-key⟩ pair.
• Therefore, if I already know that Meg’s public key is 🔓M then I can
trust that she is the author of the statement “Meg likes beets”.
• Meg cannot claim that she does not like beets (non-repudiation).

• But, how do I know 🔓M is really her public key? transitive trust…


12
But what is the “signature” itself ?
• Signing is generating and publishing a number (signature).
• The number is associated with a message (document), and a public key.
• The number is computationally infeasible to calculate without knowing
the private key.
• Hence, the fact that the number is known by anyone implies that the
holder of the private key chose to generate it.
• Anyone can verify that the number is correct using the document and
the public key.
13
Digital signatures can provide transitive trust
• Let’s say I want to browse the web and securely visit thousands of
websites over the lifetime of the computer.
• It’s impractical to get a pre-shared key ahead of time from these
thousands of websites, yet I still wish to communicate securely.
• However, I can easily get just a few trusted public keys:
• These are called root authorities.
• Root authority can sign a certificate identifying another trustworthy
certificate authority.
• Website operator must get their HTTPS public keys (certificates)
signed by a certificate authority
• Certificate authority does some kind of check that the person asking for the
certificate really represents the domain & organization listed on the cert.
• Website then advertises that certificate, proving that their public key is
legit.
14

Demo of SSL chain of trust


https://northwestern.edu
15
Public Key Infrastructure (PKI)
• PKI creates, distributes, and verifies stranger’s claims (certificates).
• A distributed and scalable way to verify public keys.
• At first, client does not trust server, however server provides two
certificates which are sufficient to earn the customer’s trust:
• Chain of trust links the advertised public key to an already-trusted key.

Server certificate
Intermediate certificate
Customer www.shopping.com Webbycorp
Root certificate Public key: e231… Certificate
authority
Public key:
904e… www.shopping.com
Crosby corporation
Root certificate
Public key:
BakerRoot 0c92…
corporation Signed by: Webbycorp Signed by:
AAA corp.
certificate
Public key: 0c92… Public key: 904e… Public
key: 0c92…
Actalis Inc.
Root certificate
Signature: 3902… Signature:
0032…
Public
AAAkey: 493a…
corporation
Public key: 0c92…
16
Getting a certificate
• Pay a fee to a certificate authority and send them a How to verify
requester's
certificate signing request (CSR): identity?
STOP
“Common name: northwestern.edu; Public key: 3a203c…” and
THINK

• Certificate authority (CA) somehow verifies the claim in the certificate:


• Email the registrant listed in the WHOIS database.
• Look up the phone number of the requester and call them.
• Send a letter to the requester and wait for a reply.
• Visit the requester’s office and verify the public key in-person.
• Challenge the requester to post a random number/document on their
webpage or in a DNS record.
• If the CA is satisfied, it will compute a digital signature certifying the
claims in the CSR, and send you the certificate (CSR + signature).
17
Mac OS comes with 170 root certificates
18
Root certificate components
• Expiration date
• Subject’s name
• Issuer name
• Issuer’s signature algorithm
• Public key of subject
• Issuer’s signature

Root certificates are self-issued and


self-signed. The user must have
some outside reason to trust it.
19
Intermediate certificate
• Has same basic components as
root certificate.
• Must be signed by a trusted issuer.
• This certificate was issued by a
root authority at the same
company:
“thawte SHA256 SSL CA”
is signed by
“thawte Primary Root CA - G3”
20
21
22
23
User can add and remove root certificates
• This controls which organizations (and public keys) are trusted to
vouch for others. STOP

• What would happen if you removed lots of these root certificates?


and

THINK

• Many HTTPS websites (and other SSL connections) would stop working.
STOP
• What would happened if you added a “bad” root certificate? and

THINK

• Your web browser would trust public keys that may be invalid, making you
vulnerable to a man-in-the-middle or other impersonation attack.
MITM Attack Revisited
G

24
A
(🔑G,🔓G)
(🔑A,🔓A)
(🔑M,🔓M)

gadgets.com
Here’s my public key 🔓A
Let’s talk securely!

Here’s my public key🔓M


Let’s talk securely!

OK. Here’s my
public key 🔓G
and my
signed certificate 📄G
OK. Here’s my public key 🔓M
and (an invalid) certificate 📄M
STOP
and Server
does not notice the attack
THINK
Client notices that certificate is fake
because it doesn’t expect a
📄M must have one of Why?
or missing. A real certificate these problems: signed
certificate from client.
authority would not have signed a • Domain name is not
Instead, passwords are usually
“gadgets.com” used
to authenticate clients.
certificate listing 🔓M as the public • Signature is invalid.
key for gadgets.com. • Issuer is not trusted.
Client drops the connection.
25
Sketchy root certificates allow MITM attacks
• Some corporate and campus networks require machines to install a
new root certificate to connect to networked services.
• By installing a single malicious root certificate, all of client’s encrypted
network traffic can be read and modified.
• This technique is also used by some legitimate debugging tools (eg.
Charles Proxy) to sniff HTTPS traffic.
• Normally, Wireshark cannot view HTTPS traffic because it’s encrypted at the
application layer.
• Charles Proxy is a MITM running on your machine that shows decrypted
HTTPS streams.
A
Successful MITM Attack
G

26
(🔑A,🔓A)
(🔑G,🔓G)
(🔑M,🔓M)
(🔑B,🔓B)
gadgets.com
Here’s my public key 🔓A
Root certificate
Let’s talk securely!
Big Brother
Here’s my
public key🔓M
Let’s talk
securely!
Pub key: 🔓B

OK.
Here’s my public key 🔓G

and my certificate 📄G
(signed
by a legitimate authority)

MITM creates a new certificate 📄M for gadgets.com


and signs it using Big Brother’s private key 🔑B
OK. Here’s my public key 🔓M
and my certificate 📄M
(signed by “Big Brother”).

Client accepts the connection PKI failed because


the client installed a root
because Big Brother has been certificate from a
malicious party who is willing to
installed as a trusted root authority. sign fake
certificates.
27
Certificate Revocation Lists (CRLs)
• Private keys are supposed to be kept private, but mistakes happen.
• What happens if someone steals the private key on the
www.mccormick.northwestern.edu webserver?
• A trusted certificate authority has already issued a certificate saying the
corresponding public key is valid for that domain until February 4, 2022.
• Using the private key and a copy of the certificate, the attacker can run a
webserver
impersonating www.mccormick.northwestern.edu.
• Certificate authorities maintain Certificate Revocation Lists (CRLs) listing
revoked (but unexpired) certificates. CRL web address is listed in CA cert.
• Client may consult CRL before trusting a certificate, but this is slow.
• PKI’s scalability (through transitive trust) is lost if you always double-check
with a central authority, so CRLs are usually not checked.
• In practice, losing a private key can have serious security implications.
28
2011 Comodo Hack
• Comodo is a root certificate authority, but in 2011 its certificate-
signing server was hacked.
• Attacker got a username/password for a system that Comodo had
built to allow their trusted affiliates to request digital signatures.
• Allowed attacker to generate new certificates for popular services like
Gmail, Yahoo Mail, and Hotmail.
• https://www.csoonline.com/article/2623707/hacking/the-real-security-issue-behind-
the-comodo-hack.html

• Bogus certificates were revoked and some browsers considered


dropping the Comodo root certificate.
• This would have required all their past customers to buy new certificates
from
another vendor!
29
Hashing before signing
• Notice that the digital signature algorithm
encrypts a hash of the document’s data.
• RSA can only encrypt integers m < n. 🔑
• Plaintext must be less than 1024 or 2048 bits.
Name of signer,
• Hashing maps a large document to a fixed Public key 🔓

integer range, small enough to RSA-encrypt.


Certificate
• But hashing must be done carefully!
• By signing a hash, we are actually signing an
infinite set of documents that map to that hash.
• We must be confident that the other documents
are random, not useful to attackers.
30
Hashing example
• If the hash is 256 bits, it can take 2256 different values.
• HTTPS certificates are about 2000 bits long: 22000 possible certs.
• We expect 22000/2256 ≅ 21744 such documents to share each hash value.
128-bit hash function
Name: gadgets.com
940294a9bc9233eb5829848ecb9e2482
Public key: 930a…

Name: 3kjD|Sj3;…
Hash collisions
940294a9bc9233eb5829848ecb9e2482
Public key: a329…

Name: \(we(CC1…
940294a9bc9233eb5829848ecb9e2482
Public key: 44a0…

Name: shop.com
45b798e10349ae8750cd45209809ec94
Public key: 201e…
31
Cryptographic Hash functions
If H(x) is a cryptographic hash function, it should be computationally infeasible
to:
• Map backwards from hash output to input: find x given H(x)
• Find two inputs x and y that map to the same hashed value: H(x) = H(y)

• We know that there is an infinite set of such (x,y) pairs, but the hash
function
is designed to make them nearly impossible to find.
• In particular, if we know x, we should not be able to find y in polynomial
time
such that H(x) = H(y)
• Like a good symmetric encryption algorithm, a cryptographic hash must have
good confusion and diffusion. It must behave very randomly.
• If input is called the message, the output is sometimes called the message
digest.
• SHA-1 and MD5 are examples of cryptographic hash functions.
32
Back to digital signatures
• If I sign a SHA-1 hash of a document and publish that signature, it
will be difficult for an attacker to construct a second document with
the same SHA-1 hash as the original document that I signed.
• Thus, it’s difficult for that signature to be used to falsely verify other
documents that I have not seen and signed.
• If I used a dumb hash function, like “the sum of all bytes,” forgery
would be easy:
• SUM(“fun and cats”) == SUM(“gun and bats”)
• The change f+1→g is cancelled by the change c-1→b
• Using this really bad hash function, the signature of “fun and cats”
would also be valid for “gun and bats”
33
Hash-based Message Authentication Code (HMAC)
• Public-key cryptography & digital signatures are computationally expensive.
• HMAC provides a more efficient way to authenticate public messages:
• HMAC steps:
• Assume sender and receiver have a shared secret: ⟵⟵ a new requirement :(
• MAC = hash(message +🗝)
• Send ⟨message, MAC⟩
• Anyone can read the message.
• Receiver with 🗝 can also compute the MAC to verify the received MAC.
• Again, we must use a strong cryptographic hash, like SHA-1
• We could have used 🗝 to encrypt with AES, but this is slower than a SHA-
1 hash (and maybe we want 3rd parties to see the message).
• HMAC is often used to authenticate API calls (eg., AWS REST API).
34
SSL/TLS Ethernet Packet
MAC addresses, CRC, etc.
• Transport Layer Security (TLS) is IP Packet
the Internet standard for encrypted IPEthernet
addresses,payload
TTL, etc.
communication, formerly called TCP Packet
Secure Sockets Layer (SSL). IP payload
Port #, sequence #, ack #, etc.
• A real-world implementation of TLS Record
public-key encryption and auth. TCP payload
Sequence #, length, MAC
• It’s built on top of TCP, sitting

🔒
below the application layer. HTTP Response
TLS payload
status code, content-type, etc.
• TLS payload is encrypted. Eg., this
could be an encrypted segment of <html><body><h1>My
an HTML document. great page</h1><p>…
• Defined in RFC 5246.
35
TLS handshake (after TCP handshake)
Sender and receiver must
agree on:
• encryption algorithms
eg., RSA+AES
• Shared keys. TLS
actually uses four
different keys
(sender, receiver)×(encryption, MAC)

• Other random values:


• Initialization Vector
used by AES
• Nonce
36
Packet replay attack
• Attacker cannot decrypt packets, but it can intercept and replay any
packet.
• Receiver might think that it’s valid, since it decrypts just fine. How to protect
against packet
• Solution: TLS records include sequence numbers. replay?
STOP
and
THINK

• Replayed packet would be dropped


I’m listening!
Connection A G

🔑=private key37

🔓=public key
replay attack
Generate key pair
Generate key pair
(🔑A,🔓A) (🔑
G,🔓G)
Let’s talk securely!
Here’s my public key 🔓A

OK. Here’s my public key 🔓G

🔓G
“I would like to
buy 10 widgets.” RSAe 92b102…
🔑G
92b102…

“I would like to

92b102… RSAd

buy 10 widgets.”

🔓A

“OK, it’s

RSAe 5773ae…
5773ae…
shipped.”
🔑A

5773ae… RSAd “OK, it’s


shipped.”
Network observer only sees public keys and encrypted messages. 🔑A & 🔑G are
never seen.
I don’t know what the previous messages
said, but I’ll just blindly repeat them
🔑=private key38
The replay (within a new TCP connection).

🔓=public key

I don’t have the private key 🔑A,


Generate key pair
but I can still cause trouble!
(🔑G,🔓G)
Let’s talk securely!
Here’s my public key 🔓A

OK. Here’s my public key 🔓G


I’ll just replay the encrypted
messages I observed before.
🔑G
92b102…

“I would like to

92b102… RSAd

buy 10 widgets.”

🔓A

“OK, it’s

RSAe 5773ae…
5773ae…
shipped.”
Hmm, I don’t know what
happened, but hopefully it
was something bad!
The attacker made the

customer pay for

another order!
Let’s do it again! Let’s talk securely!
Here’s my public key 🔓A
How to prevent 39
Connection replay attack STOP
and
this?
THINK

• Attacker can observe entire client-server interaction and replay it.


• Solution: receiver sends a random nonce in handshake message.
• Sender must include encrypted nonce in the next message.
• This requires each connection’s data to be at least slightly different.
• Replay will not work because original connection had a different
nonce.
Add a Nonce to prevent replay G

🔑=private key40

🔓=public key

Generate key pair


I don’t have the private key 🔑A, (🔑
G,🔓G)
but I’ll still try to cause trouble! Let’s talk securely!
Here’s my public key 🔓A

Generate a new random Nonce: 8903


OK. Here’s my public key 🔓G
I’ll just replay the encrypted Please repeat the Nonce 8903
messages I observed before.
🔑G “The Nonce is
92b102…

7344. I would

92b102… RSAd

like to buy 10

widgets.”

The server
rejects this connection because
the returned
Nonce is wrong (because it
came from
replaying a prior connection).
41
Fundamental network security lessons
• Secure communication involves many considerations.
• Encryption primitives are not enough, they must be used carefully.
• TLS must be carefully designed to avoid all kinds of clever attacks, like
replay attacks (and many others!)
• Authentication is still not a fully-solved problem,
(Public Key Infrastructure has many drawbacks).
• Learn more in CS-396 Cryptography
Lessons for the software/network engineer:
• Don’t try to build your own encryption scheme from scratch.
• Just use the latest version of TLS.
• Know the meaning of PKI/certificates, and keep private keys safe!
42
Recap
• Digital signatures are special bit sequences attached to documents
that can only be computed by the holder of a private key.
• Signatures are used to establish transitive trust and verify new public keys,
thus preventing Man In The Middle and other attacks.
• Certificate authorities verify public keys with digitally signed certificates.
• MITM with root authority’s private key can forge arbitrary certificates.
• Cryptographic hash functions are irreversible and unpredictable.
• Used to create a small summary of a document than can be signed with RSA.
• Also used in Message Authenticate Codes (HMAC) to verify that sender
has a shared secret: MAC = hash(message +🗝)
• Transport Layer Security (TLS) encrypts a TCP stream.
• Details are complex, to allow many different systems to interoperate and to
mitigate a variety of attacks: Eg., packet replay, connection replay.

You might also like