Applied Cryptography (Pt. 1) Engineering Secure Software Last - - PowerPoint PPT Presentation

SWEN-331: Engineering Secure Software Benjamin S Meyers

Applied Cryptography (Pt. 1)

Engineering Secure Software

Last Revised: October 13, 2020 1

SWEN-331: Engineering Secure Software Benjamin S Meyers

Networks, Cryptography, and You

• Most application developers

○ Don’t implement networking protocols ○ Don’t implement encryption algorithms

• Knowing how to safely deploy them, however, is paramount

○ Different situations call for different techniques ■ Types of authentication ■ One-way digests (hashes) ■ Symmetric-key vs. Public-key ■ Trusting public keys ○ Know thy algorithms instead of “just use crypto”

2

SWEN-331: Engineering Secure Software Benjamin S Meyers

The Basic Problems

• The internet is a scary, scary place

○ Anyone can join ○ Anyone can sniff

• BUT! “Distrust everything all the time” is not feasible
• Authentication: are you who you say you are?

○ Trust must be built somehow

• Encryption: can someone listen in?
• Authentication and encryption overlap in techniques

○ How do we encrypt data for someone we do not trust? ○ How do we know nobody else has the key? ○ How do we authenticate this machine?

3

SWEN-331: Engineering Secure Software Benjamin S Meyers

Multi-Factor Authentication

• Security experts recommend that we utilize three types of

authentication:

○ Something you know ■ e.g. passwords (but these can be guessed) ○ Something you have ■ Maybe a physical item ■ Maybe a one-time randomly generated key ■ e.g. Both: pre-seeded secure PRNG key fob ○ Something you are ■ Biometrics? Tons of false positives ■ Easier for humans, at least right now (e.g. facial recognition)

4

SWEN-331: Engineering Secure Software Benjamin S Meyers

Multi-Factor Authentication

• Something you know

○ e.g. passwords (but these can be guessed) ○ Which is a better password?

5

A: jK8v!ge4D B: CorrectHorseBatteryStaple

SWEN-331: Engineering Secure Software Benjamin S Meyers

Multi-Factor Authentication

• Something you know

○ e.g. passwords (but these can be guessed) ○ Which is a better password?

6

A: jK8v!ge4D

• 9 characters
• Hard to remember
• A couple days to guess

B: CorrectHorseBatteryStaple

• 25 characters
• Easy to remember
• Many lifetimes to guess

SWEN-331: Engineering Secure Software Benjamin S Meyers

Multi-Factor Authentication

• Something you have

○ Maybe a physical item ■ Authenticator app on your phone ○ Maybe a one-time randomly generated key ○ e.g. Both: pre-seeded secure PRNG key fob ■ YubiKey (or similar)

7 Source: https://www.yubico.com/ Source: https://blockspot.io/

SWEN-331: Engineering Secure Software Benjamin S Meyers

Verifying Integrity of Data

• Compare data to “known correct answer”

○ Not in “plain text” ○ Need “obfuscated” version of “the truth”

• Using a hash digest

○ A variable-length plaintext is “hashed” into a fixed-length hash value, often called a “message digest” or “hash” ○ Hash functions verify integrity ○ The digest is sensitive to changes in the source data

8

SWEN-331: Engineering Secure Software Benjamin S Meyers

Hash Collisions

• By definition, hash digests cannot uniquely map data to hash

○ Thus, many pieces of data can map to the same hash ○ A collision is 2+ known pieces of data that map to the same hash ○ Can be used to “spoof” a password

• MD4, MD5, SHA1 are now considered “broken” (thus insecure)

○ Colliding digests can be manufactured ○ Creating a rogue cert using hash collisions in MD5 ○ Still cannot be reversed, and probably won’t be ○ Password crackers: JohnTheRipper, Brutus, rainbowcrack, cainandabel

• Recommendation: SHA2 (256bit)

9

SWEN-331: Engineering Secure Software Benjamin S Meyers

Authentication with Hash Digests

• Problem: sensitive data needs to be identified only by the
• riginal user, nobody else

○ e.g. user wants to authenticate, but we don’t want to store passwords in plaintext in case an attacker breaks in

• Solution: hash digest algorithms

○ Compute a very large number based on a chunk of data ■ The more numbers it can map to, the better (e.g. 2128) ■ Similar chunks of data should not compute the same hash ○ Same number? Highly probable it’s the same data

10 10

SWEN-331: Engineering Secure Software Benjamin S Meyers

Authentication with Hashes

• Use case: (re)set password

○ User inputs password ○ Server hashes password ○ Server stores hash

11 11

Database Server Bobby

Already authenticated set pwd=“xkcd327” SHA512(“xkcd327”) Done! Done! store Bobby:cc4b3...

SWEN-331: Engineering Secure Software Benjamin S Meyers

Authentication with Hashes

• Use case: (re)set password

○ User inputs password ○ Server hashes password ○ Server stores hash

• Abuse Case: break-in

○ Attacker steals plaintext passwords from database ○ Harm done: can authenticate as any user ○ Mitigation: hashes can’t be reversed

12 12

Database Server Bobby

Already authenticated set pwd=“xkcd327” SHA512(“xkcd327”) Done! Done! store Bobby:cc4b3...

SWEN-331: Engineering Secure Software Benjamin S Meyers

Authentication with Hashes

• Use case: authenticate

○ User inputs password ○ Server computes hash ○ Server compares computed hash with stored hash

13 13

Database Server Bobby

login pwd=“xkcd327” Is Bobby SHA512(“xkcd327”)? Yes! Come on in!

SWEN-331: Engineering Secure Software Benjamin S Meyers

Abuse Case: Rainbow Tables

• What if an attacker steals the hashes?

○ Common passwords + common digests = common hashes ○ Thus, attackers have large databases of pre-computed hashes called rainbow tables

• Solution: hashing with salt

○ What is salt? Today’s VOTD

14 14

SWEN-331: Engineering Secure Software Benjamin S Meyers

Salt & Pepper

• Salt:

○ Add a random string (salt) to the password before hashing ○ Store hash and salt ○ Salt only has to be long enough to be unique

• Pepper:

○ Add a random string (pepper) to the password before hashing ○ Do not store the pepper, or store it in another location ○ Pepper has to be long enough to remain secret (<= 112 bits)

15 15

SWEN-331: Engineering Secure Software Benjamin S Meyers

Symmetric-Key Cryptography

• Encrypt key == Decrypt key (shared secret)

○ So keep that key a secret! ○ Traditional arrangement

• Modern algorithms

○ e.g. AES, Blowfish, 3DES

• Fastest and mathematically strongest form of cryptography
• Traditional usage

○ Encryption of data storage: backups, hard drives, etc. ○ Networking situations: once you exchange the key!

16 16

SWEN-331: Engineering Secure Software Benjamin S Meyers

Public-Key (Asymmetric) Cryptography

• Encrypt key is public, decrypt key is private

○ Anyone in the world can encrypt data and send it to you ○ But they can’t decrypt any other messages sent to you

• Most popular modern algorithm: RSA

○ Factorization of two prime numbers ○ Public/private keys generated from computing two very large prime numbers

• RSA has never been cracked, although…

○ The algorithms for generating very large prime numbers have been cracked and are often poorly implemented ○ Result of poor PRNG practices (bad algorithms and bad seeds)

• Traditional usage: networking (SSH, SSL, PGP)

17 17

SWEN-331: Engineering Secure Software Benjamin S Meyers

Symmetric vs. Asymmetric Encryption

18 18 Source: https://www.101computing.net/symmetric-vs-asymmetric-encryption/

SWEN-331: Engineering Secure Software Benjamin S Meyers

Public-Key Authentication

• Key:

○ E[..] is encrypt (public) ○ D[..] is decrypt (private) ○ D[E[m]]=m is encrypt then decrypt m (normal usage) ○ D[m] is use the decryption on plain text m (strange, but legal)

• Scenario: Adam and Eve

○ Adam’s public and private: EAdam[..] and DAdam[..] ○ Eve’s public and private: EEve[..] and DEve[..] ○ They know each others’ public keys

• Adam wants to ensure Eve that the message came from him

○ So he does m=“This should be bubbles: DAdam[bubbles]” ○ Sends EEve[m] to Eve -- only Eve can read the message with DEve[m] ○ Eve checks EAdam[DAdam[bubbles]]=bubbles to be sure that the message came from Adam

19 19

SWEN-331: Engineering Secure Software Benjamin S Meyers

Public/Private Key Encryption

20 20

Message Encrypted Message Encrypted Message Message

User 2 Public Key User 2 Private Key

User 1 User 2

SWEN-331: Engineering Secure Software Benjamin S Meyers

Digital Signing

21 21

Message Signed Message Signed Message

‘Validated’ Message User 1 Private Key User 1 Public Key

User 1 User 2

• Validation:

○ Message has not been modified ○ Message came from a known sender

• Message is NOT encrypted

SWEN-331: Engineering Secure Software Benjamin S Meyers

Drawbacks of Public Key

• Implementation issues

○ Tends to be slower than traditional symmetric key ○ Generating primes with 50+ digits is hard (and expensive)

• How do we trust the public key?

○ What if Eve confuses EAdam with ESatan? ○ Man-in-the-Middle attack ■ Satan intercepts Eve’s message, decrypts it, reads it, re-encrypts it properly, and sends it off to Adam

22 22

Adam Satan Eve

Eve thinks ESatan = EAdam ESatan[m] m=“We should grab lunch.” DSatan[m] EAdam[m] Satan reads message

SWEN-331: Engineering Secure Software Benjamin S Meyers

Public-Key + Symmetric Key

• In SSH, SSL, PGP, the two methodologies are combined
• Use a secure PRNG to generate a random symmetric key

nonce (aka “ephemeral key”)

○ Nonce: “number used once”

• Use public-key to swap the symmetric keys

○ 99% of communication? Symmetric key ○ End of communication? Throw away symmetric key

23 23

SWEN-331: Engineering Secure Software Benjamin S Meyers

Overview of SSL/TLS Handshake

24 24 (3) Verify server cert; check crypto. params

SSL Client

(6) Verify client cert (if required)

SSL Server (1) “client hello” -- Cryptographic information

(2) “server hello” -- CipherSuite; Server cert; “client cert request” (optional) (4) Client key exchange -- send secret key info (encrypted w/ server public key)

(5) Send client certificate (7) Client “finished” (8) Server “finished” (9) Exchange messages (encrypted with shared secret key)

SWEN-331: Engineering Secure Software Benjamin S Meyers

SSL Details

• Agree on the version of the protocol to use.
• Select cryptographic algorithms.
• Authenticate each other by exchanging and validating digital certificates.
• Use asymmetric encryption techniques to generate a shared secret key, which avoids the key distribution problem. SSL or TLS then uses the shared key for

the symmetric encryption of messages, which is faster than asymmetric encryption.

• For more information about cryptographic algorithms and digital certificates, refer to the related information.
• This section does not attempt to provide full details of the messages exchanged during the SSL handshake. In overview, the steps involved in the SSL

handshake are as follows:

• The SSL or TLS client sends a client hello message that lists cryptographic information such as the SSL or TLS version and, in the client's order of preference,

the CipherSuites supported by the client. The message also contains a random byte string that is used in subsequent computations. The protocol allows for the client hello to include the data compression methods supported by the client.

• The SSL or TLS server responds with a server hello message that contains the CipherSuite chosen by the server from the list provided by the client, the

session ID, and another random byte string. The server also sends its digital certificate. If the server requires a digital certificate for client authentication, the server sends a client certificate request that includes a list of the types of certificates supported and the Distinguished Names of acceptable Certification Authorities (CAs).

• The SSL or TLS client verifies the server's digital certificate. For more information, see How SSL and TLS provide identification, authentication,

confidentiality, and integrity.

• The SSL or TLS client sends the random byte string that enables both the client and the server to compute the secret key to be used for encrypting

subsequent message data. The random byte string itself is encrypted with the server's public key.

• If the SSL or TLS server sent a client certificate request, the client sends a random byte string encrypted with the client's private key, together with the

client's digital certificate, or a no digital certificate alert. This alert is only a warning, but with some implementations the handshake fails if client authentication is mandatory.

• The SSL or TLS server verifies the client's certificate. For more information, see How SSL and TLS provide identification, authentication, confidentiality, and

integrity.

• The SSL or TLS client sends the server a finished message, which is encrypted with the secret key, indicating that the client part of the handshake is

complete.

• The SSL or TLS server sends the client a finished message, which is encrypted with the secret key, indicating that the server part of the handshake is

complete.

• For the duration of the SSL or TLS session, the server and client can now exchange messages that are symmetrically encrypted with the shared secret key.

25 25

SWEN-331: Engineering Secure Software Benjamin S Meyers

SSH

• Secure Shell

○ Used for remote access into machines ○ Ubiquitous for Unix-like systems ○ Uses passwords by default

• SSH and public keys

○ Key pairs have a one-time PRNG built in ○ Private key

■ Encrypted with a symmetric cipher ■ Requires a “passphrase” to unlock

○ Trust the public keys? ~/.ssh/authorized_keys ○ Trust the host? ~/.ssh/known_hosts

• Thus, symmetric keys are used twice with SSH

○ Passphrase: encrypt your private key (in case it’s stolen) ○ In transit: using an ephemeral key (nonce)

26 26

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example: SSH Key Pairs

○

27 27

me@client$ ssh-keygen –t rsa Generating public/private rsa1 key pair... Enter file in which to save the key (~/.ssh/identity): Enter passphrase: Enter same passphrase again: Your public key has been saved in ~/.ssh/id_rsa.pub Your private key has been saved in ~/.ssh/id_rsa The key fingerprint is: 22:bc:0b:fe:f5:06:1d:c0:05:ea:59:09:e3:07:8a:8c

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example: SSH Key Pairs

• Untrusted public keys?

○ SSH-enabled servers don’t trust any public keys initially ○ Need to copy your public key to the authorized_keys file on the server

28 28

me@client$ ssh-keygen –t rsa Generating public/private rsa1 key pair... Enter file in which to save the key (~/.ssh/identity): Enter passphrase: Enter same passphrase again: Your public key has been saved in ~/.ssh/id_rsa.pub Your private key has been saved in ~/.ssh/id_rsa The key fingerprint is: 22:bc:0b:fe:f5:06:1d:c0:05:ea:59:09:e3:07:8a:8c me@client$ scp ~/id_rsa.pub me@server.edu:~ me@client$ ssh me@server.edu me@server$ cat id_rsa.pub >> ~/.ssh/authorized_keys OR me@client$ ssh-copy-id -i ~/.ssh/id_rsa.pub me@server.edu

SWEN-331: Engineering Secure Software Benjamin S Meyers

SSH & known_hosts

• When you SSH into a server, how do you know that it isn’t a

malicious server with a modified network address?

• Answer: your known_hosts file

○ Every server has a unique fingerprint ○ First time you sign in, trust the key and add it to your known_hosts ○ Host changes? You’ll get a warning like this:

29 29

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been

• changed. The fingerprint for the RSA key sent by the remote host is

8b:ff:a1:b5:08:2f:8f:fd:2e:2f:67:80:9e:ba:8d:ff. Please contact your system administrator. Add correct host key in /home/bob/.ssh/known_hosts to get rid of this message. Offending key in /home/bob/.ssh/known_hosts:2 RSA host key for 192.168.1.100 has changed and you have requested strict checking. Host key verification failed.

SWEN-331: Engineering Secure Software Benjamin S Meyers

to be continued...

30 30

Source: https://xkcd.com/936/