CS代写 CSE 127: Introduction to Security

CSE 127: Introduction to Security
TLS and Secure Channels

Spring 2022

Some material from , , ,

Reminder: Cryptographic primitives
Confidentiality
Symmetric crypto
Symmetric encryption (e.g. AES)
Public-key crypto
Public-key encryption (e.g. RSA)
Digital signatures
Integrity/Authenticity

Reminder: Network Attacker Threat Model
Network Attacker:
• Controlsinfrastructure:Routers,DNS
• Eavesdrops,injects,drops,ormodifiespackets
• WiFiatinternetcafe
• Internetaccessathotels
Goal: Establish a secure channel to a host that ensures • ConfidentialityandIntegrityofmessages
• Authenticationoftheremotehost

Common cryptographic network protocols
• TLS(TransportLayerSecurity)
• Used to provide an encryption wrapper around HTTP to make HTTPS, and for many other application layer protocols.
• Security goals: Authenticate server, confidentiality and integrity of traffic
• SSH(SecureShell)
• Use to access remote machines
• Security goals: Authenticate server and client,
confidentiality and integrity of traffic
• IPsec(InternetProtocolSecurity)
• Provides an encrypted, authenticated alternative to IP
• Commonly used for VPNs (Virtual Private Networks)
• Security goals: client and server authentication,
authenticate headers, optionally encrypt headers, ensure confdentiality and integrity of payloads

Constructing a secure encrypted channel
• To ensure confidentiality and integrity: Encrypt and MAC data
c = AESke(m),t = MACkm(c)

Constructing a secure encrypted channel
• To ensure confidentiality and integrity: Encrypt and MAC data
• To negotiate shared symmetric keys: Diffie-Hellman key exchange. Key Derivation Function (KDF) maps shared secret to symmetric key.
• To ensure authenticity of endpoints: Digital Signatures
• To ensure an adversary can’t reuse a signature later, add
some random unique values (“nonces”) ga, random ra gb, random rb
RSApubB , SignB (ga, gb, ra, rb) c = AESke(m),t = MACkm(c)
ke,km =KDF(gab,ra,rb)
This is not exactly what TLS looks like, but it’s similar.
ke,km =KDF(gab,ra,rb)

Constructing a secure encrypted channel
• To ensure confidentiality and integrity: Encrypt and MAC data
• To negotiate shared symmetric keys: Diffie-Hellman key exchange. Key Derivation Function (KDF) maps shared secret to symmetric key.
• To ensure authenticity of endpoints: Digital Signatures
• To ensure an adversary can’t reuse a signature later, add
some random unique values (“nonces”) ga, random ra gb, random rb
RSApubB , SignB (ga, gb, ra, rb) c = AESke(m),t = MACkm(c)
ke,km =KDF(gab,ra,rb)
How does Alice know to trust Bob’s public signing key?
ke,km =KDF(gab,ra,rb)

Public Key Infrastructure: Establishing Trust in Keys
Ways to establish trust in keys:
• Meetinpersontoexchangekeys.
• Not practical at scale over the internet

Public Key Infrastructure: Establishing Trust in Keys
Ways to establish trust in keys: • Fingerprintverification
• Verify a cryptographic hash of a public key through a separate channel, or “trust on first use” (TOFU).
• This is used by SSH for host keys.
$ ssh elk.sysnet.ucsd.edu
Theauthenticity of host ’elk.sysnet.ucsd.edu (137.110.222.162)’ can’t be established.
ED25519 key f i n g e r p r i n t i s SHA256:rI/PqZezDo18EbK8U8/HXesuO7iCoNUGa+8r3t3qGxw. This key i s not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Public Key Infrastructure: Establishing Trust in Keys
Ways to establish trust in keys:
• CertificateAuthorities
• A certificate authority (CA) is a kind of commercial trusted intermediary.
• Certificate Authorities verify public keys and sign them in exchange for money.
• If you trust the certificate authority, you transitively trust the keys it signs.
• This is used for TLS, software signing keys.

Public Key Infrastructure: Establishing Trust in Keys Ways to establish trust in keys:
• WebofTrust(e.g.,PGPG)
• In a web of trust, you establish trust in intermediaries of
your choice.
• You then transitively trust the keys they sign.
$ gpg –edit-key
gpg (GnuPG) 2.2.29; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute i t .
There is NOWARRANTY, to the extent permitted by law.
pub dsa1024/702353E0F7E48EDB
created: 2004-01-05 expires: 2022-07-05 usage: SC trust: unknown validity: unknown
sub elg1024/0296C3D9E4374AE1
created: 2004-01-05 expires: never usage: E
[ unknown] (1). ThomasDickey gpg> trust pub dsa1024/702353E0F7E48EDB
created: 2004-01-05 expires: 2022-07-05 usage: SC trust: unknown validity: unknown
sub elg1024/0296C3D9E4374AE1
created: 2004-01-05 expires: never usage: E
[ unknown] (1).
Please decide howfar you trust this user to correctly verify other users’ keys (by looking at passports, checking fingerprints from different sources, etc.)
1 = I don’t know or won’t say 2=I doNOTtrust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menuYour decision?

A more modern and practical WoT: Keybase
Disclaimer: Available on Keybase.
https://keybase.io/

TLS: Transport Layer Security
• TLSprovidesanencryptedchannelforapplicationdata.
• UsedforHTTPS:HTTPinsideofaTLSsession
• Used to be called SSL (Secure Sockets Layer) in the 90s.
SSL1.0 Terribly insecure; never released.
Released 1995; terribly insecure, deprecated in 2011
Released 1996; insecure, deprecated in 2015.
TLS1.3 Standardized in August 2018 and is being
Released 1999; deprecated in 2020. Released 2006; deprecated in 2020. Released 2008. Ok.
rolled out now; major change from TLS1.2.

TLS 1.2 with Diffie- Exchange Step 1: The client (browser) tells the server what kind of cryptography it supports.
client hello: client random [list of cipher suites]
Cipher suites: list of options like:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
This says to use
• elliptic curve Diffie-Hellman for key exchange
• RSA digital signatures
• 128-bit AES for symmetric encryption
• GCM (Galois Counter Mode) AES mode of operation
• SHA-256 for hash function

TLS 1.2 with Diffie- Exchange Step 1: The client (browser) tells the server what kind of cryptography it supports.
client hello: client random [list of cipher suites]
Cipher suites: list of options like:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Server cipher suite confguration can be confusing and difficult for sysadmins. Many insecure options like
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_NULL_WITH_NULL_NULL
Subtle protocol errors around cipher suite negotiation.

TLS 1.2 with Diffie- Exchange
Step 2: The server tells the client which kind of cryptography it wishes to use.
client hello: client random [list of cipher suites]
server hello: server random, [cipher suite]

TLS 1.2 with Diffie- Exchange
Step 3: The server sends over its certifcate which contains the server’s public key and signatures from a certifIcate authority.
client hello: client random
[list of cipher suites]
server hello: server random, [cipher suite] certificate = public RSA key + CA signatures

Certificates and Certificate Authorities in TLS
Website public keys are encoded into certificates. Certificates signed by CAs.
Browsers come with set of trusted CAs.
To verify a certificate, browsers verify chain of digital certificates back to trusted root CA.
Certificates typically valid for 3 months to multiple years.

Sample certificate

Who are we trusting?

Who are we trusting?
Who is this cert for?

Who is this cert for?

CSE’s pub key info

Where we should check for revocation information

Revocation
• Problem:keysgetcompromised
• Attacker with a key can impersonate you and read messages encrypted to you
• Keyexpirationhelps,butnotenough • CAandPGPPKIssupportrevocation
• “I, Alice, revoke my public key . . . do not use it.”
• Signs revocation with her private key
• Others can verify Alice’s signature, stop using key

Root CAs on OS X
Which CA can issue a certificate for fbi.gov? Which CA can issue a certificate for google.com?

Man-in-the-middle attack using rogue cert
Attacker proxies data between user and bank. Sees all traffic and can modify data at will.
https://www.microsoft.com/en-us/research/publication/detection-of-rogue-certi%EF%AC%81cates-from-trusted-certi%EF%AC%81cate- authorities-using-deep-neural-networks/

CA Hacks and Vulnerabilities
There is a long history of CAs getting hacked or doing the wrong thing.
• 2011: Comodo and DigiNotar CAs hacked, used to issue fraudulent certificates for Hotmail, Gmail, Skype, Yahoo Mail, Firefox…
• Fraudulent certifcates later used in man-in-the-middle attack against Iran.
• 2013:TurkTrustissuedfraudulentcertifcateforGmail.
• 2014:IndianNICissuecertsforGoogleandYahoo!
• 2016:WoSignissuescertforGitHub.
Mitigations:
• Certificatepinning.
• Hard code certificates for some sites in browser.
• CertificateTransparency.
• Public append-only log of certificate issuances to track fraudulent certs.

TLS 1.2 with Diffie- Exchange
Step 3: The server sends over its certifcate which contains the server’s public key and signatures from a certifcate authority.
client hello: client random
[list of cipher suites]
server hello: server random, [cipher suite] certifcate = public RSA key + CA signatures

TLS 1.2 with Diffie- Exchange
Step 4: The server initiates a Diffie-Hellman key exchange.
client hello: client random
[list of cipher suites]
server hello: server random, [cipher suite] certifcate = public RSA key + CA signatures server kex: p, g , g a, SignRSAkey(p, g , g a)
To protect against man-in-the-middle attacks, the server uses its public key to sign the Diffie-Hellman key exchange.
TLS also allows client authentication, but this is rare.

TLS 1.2 with Diffie- Exchange
Step 5: The client responds with its half of the Diffie-Hellman key exchange.
client hello: client random
[list of cipher suites]
server hello: server random, [cipher suite] certifcate = public RSA key + CA signatures serverkex: p,g,ga,SignRSAkey(p,g,ga)
client kex: gb

TLS 1.2 with Diffie- Exchange
Step 6: The client and server derive symmetric encryption keys from the shared secret using a key derivation function.
client hello: client random
[list of cipher suites]
server hello: server random, [cipher suite] certifcate = public RSA key + CA signatures serverkex: p,g,ga,SignRSAkey(p,g,ga)
client kex: gb
KDF(g ab , random) → kmc ,kms,ke
KDF(g ab , random) → kmc , kms , ke

TLS 1.2 with Diffie- Exchange Step 7: The client and server verify the integrity of the handshake using the MAC keys they have derived.
client hello: client random
[list of cipher suites]
server hello: server random, [cipher suite] certifcate = public RSA key + CA signatures serverkex: p,g,ga,SignRSAkey(p,g,ga)
KDF(gab, random) → kmc , kms , ke
client kex: gb
client fnished: MACk (dialog)
server fnished: MAC
KDF(gab, random) → kmc , kms , ke

TLS 1.2 with Diffie- Exchange Step 8: The client and server can now send encrypted application data (e.g. HTTP) using their secure channel.
client hello: client random
[list of cipher suites]
server hello: server random, [cipher suite] certifcate = public RSA key + CA signatures serverkex: p,g,ga,SignRSAkey(p,g,ga)
KDF(gab, random) → kmc , kms , ke
client kex: gb
client fnished: MACk (dialog)
server fnished: MAC Encke (request)
KDF(gab, random) → kmc , kms , ke

TLS 1.2 with RSA Key Exchange
TLSversions prior to 1.3 also supported using RSApublic key encryption to share the premaster secret (shared secret master key).
client hello: client random
[supported cipher suites]
server hello: server random, [RSA cipher suite] certifcate = RSA pubkey k2048 + CA signatures
client key exchange: RSAenck2048 (pms) client fnished: Authkmc (dialog)
KDF(pms , random) → kmc ,kms,ke
KDF(pms , random) → kmc , kms , ke

TLS 1.2 with RSA Key Exchange
TLSversions prior to 1.3 also supported using RSApublic key encryption to share the premaster secret (shared secret master key).
client hello: client random
[supported cipher suites]
server hello: server random, [RSA cipher suite] certifcate = RSA pubkey k2048 + CA signatures
KDF(pms, random) → kmc , kms , ke
client key exchange: RSAenck2048 (pms) client fnished: Authkmc (dialog)
server fnished: Authkm (dialog) s
KDF(pms , random) → kmc ,kms,ke

TLS 1.2 with RSA Key Exchange
TLSversions prior to 1.3 also supported using RSApublic key encryption to share the premaster secret (shared secret master key).
client hello: client random
[supported cipher suites]
server hello: server random, [RSA cipher suite] certifcate = RSA pubkey k2048 + CA signatures
k ,k ,k mc ms e
client key exchange: RSAenck2048 (pms) client fnished: Authkmc (dialog)
server fnished: Authkm (dialog) s
Enck (request) e
KDF(pms , random) → kmc ,kms,ke

How TLS achieves its security goals
• Whathappensifapassiveeavesdropperwatchesall the traffic?

How TLS achieves its security goals
• Whathappensifapassiveeavesdropperwatchesallthe traffic?
• The application-layer traffic is encrypted, and Diffie-Hellman and RSAare secure against a passive eavesdropper so the attacker cannot discover the keys.
• The eavesdropper can see all the IP and TCP-layer packet headers.
• The eavesdropper can also see the initial handshake and metadata (which includes the server certifcate)

How TLS achieves its security goals
• Whathappensifanactiveattackertriestoman-in-the- middle the connection?

How TLS achieves its security goals
• Whathappensifanactiveattackertries
to man-in-the-middle the connection?
• For Diffie-Hellman, the key exchange is digitally signed by the private key corresponding to the public key in the server’s certificate and the attacker doesn’t know the server’s key, so they cannot forge the signature. The client will not accept the key exchange.
• For RSA, the attacker does not know the private key corresponding to the public key in the server’s certificate, so cannot learn the client’s choice of premaster secret to learn the session keys.

How TLS achieves its security goals
• Whathappensifanetworkattackertries to impersonate the server?

How TLS achieves its security goals
• Whathappensifanetworkattackertries to impersonate the server?
• For Diffie-Hellman, the attacker does not know the private key corresponding to the public key in the server’s certifcate, so they cannot generate a valid signature on their Diffie-Hellman key exchange that will be accepted by the client.
• For RSA the attacker does not know the server’s private key so cannot decrypt the client’s encrypted premaster secret message.

What if a private key gets stolen or compromised?
If an adversary obtains a server certifcate private key:
• WithDiffie-Hellmankeyexchange,theadversarycan:
• actively man-in-the-middle a connection.
• impersonate the server to anyone.
• WithRSAkeyexchange,theadversarycan:
• impersonate the server to anyone.
• decrypt any traffic from now and any point in the past.

TLS v. 1.2 and below have had a lot of vulnerabilities
• EarlyversionsofSSLdevelopedbeforecryptographic protocol design was fully understood.
• Laterprotocolversionsretainedinsecureoptionsfor backwards compatibility.

TLS 1.3 is the new standard
Developed over several years as a collaboration between cryptographers from industry and academia.
Standardized August 2018 by IETF.
Major differences from TLS1.2 and below: • RSAkeyexchangeremoved.
• Protects against passive decryption attacks.
• OnlysecureDiffie-Hellmanparametersallowed.
• Protects against attacks exploiting bad choices of parameters.
• Handshakeencryptedimmediatelyafterkeyexchange.
• Limits the amount of metadata visible to a passive eavesdropper.
• Protocoldowngradeprotection.
• Protects against protocol being downgraded to prior insecure versions.

TLS 1.3 encrypts the handshake immediately after doing a Diffie-Hellman key exchange.
client hello: client random, DH key exchange
server hello: server random, DH key exchange Encrypted certifcate Encrypted signature of handshake
server fnished
KDF(pms , random) → kmc , kms , ke
KDF(pms , random) → kmc , kms , ke

TLS 1.3 encrypts the handshake immediately after doing a Diffie-Hellman key exchange.
client hello: client random, DH key exchange
server hello: server random, DH key exchange Encrypted certifcate Encrypted signature of handshake
server fnished
client finished
KDF(pms , random) → kmc ,kms,ke
KDF(pms , random) → kmc , kms , ke

TLS 1.3 encrypts the handshake immediately after doing a Diffie-Hellman key exchange.
client hello: client random, DH key exchange
server hello: server random, DH key exchange Encrypted certifcate Encrypted signature of handshake
server fnished
client finished
KDF(pms , random) → kmc ,kms,ke
k ,k ,k mc ms e
Enck (request) e

TLS 1.3 deployment difficulties
TLS 1.3 deployment is slower than it should be, but now ≈ 63% of TLS traffic (f5 labs).
Major reasons:
• HTTPSproxiesextremelycommoninindustry.
• ManyofthemrelyonRSAkeyexchangetomake passive decryption and traffic analysis easier.
• RemovingRSAkeyexchangebreaksalltheseboxes.
• Man-in-the-middlehardwareisalsoquitecommon.
• Badimplementationshavehard-codedvalueslikeTLS versions and there is no way to update them.

END: Cryptography and TLS
Readmore:TLSkey theft and other risks in the wild
https://www.theguardian.com/world/2013/oct/03/lavabit-ladar-levison-fbi- encryption-keys-snowden

August 2013

https://xkcd.com/538/
“Actual actual reality: nobody cares about his secrets. Also, I would be hard-pressed to f n d that wrench for $5.”

The “crypto wars” and the historical development of TLS.

International Traffic in Arms Regulations April 1, 1992 version
Category XIII–Auxiliary Military Equipment . . .
(b)Information Security Systems and equipment, cryptographic devices, software, and components specifically designed or modified therefore, including:
(1)Cryptographic (including key management) systems, equipment, assem

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts