Applied Cryptography (Pt. 1) Engineering Secure Software Last Revised: October 13, 2020 SWEN-331: Engineering Secure Software Benjamin S Meyers 1
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” ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 2
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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 3
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) ■ SWEN-331: Engineering Secure Software Benjamin S Meyers 4
Multi-Factor Authentication Something you know ● e.g. passwords (but these can be guessed) ○ Which is a better password? ○ A: jK8v!ge4D B: CorrectHorseBatteryStaple SWEN-331: Engineering Secure Software Benjamin S Meyers 5
Multi-Factor Authentication Something you know ● e.g. passwords (but these can be guessed) ○ Which is a better password? ○ A: jK8v!ge4D B: CorrectHorseBatteryStaple 9 characters 25 characters ● ● Hard to remember Easy to remember ● ● A couple days to guess Many lifetimes to guess ● ● SWEN-331: Engineering Secure Software Benjamin S Meyers 6
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) ■ Source: https://blockspot.io/ Source: https://www.yubico.com/ SWEN-331: Engineering Secure Software Benjamin S Meyers 7
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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 8
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) ● SWEN-331: Engineering Secure Software Benjamin S Meyers 9
Authentication with Hash Digests Problem: sensitive data needs to be identified only by the ● original 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. 2 128 ) ■ Similar chunks of data should not compute the same hash ■ Same number? Highly probable it’s the same data ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 10 10
Authentication with Hashes Use case: (re)set password ● Bobby Server Database User inputs password ○ Already Server hashes password ○ authenticated Server stores hash ○ set pwd=“xkcd327” SHA512(“xkcd327”) store Bobby:cc4b3... Done! Done! SWEN-331: Engineering Secure Software Benjamin S Meyers 11 11
Authentication with Hashes Use case: (re)set password ● Bobby Server Database User inputs password ○ Already Server hashes password ○ authenticated Server stores hash ○ set pwd=“xkcd327” Abuse Case: break-in ● SHA512(“xkcd327”) Attacker steals plaintext ○ store Bobby:cc4b3... passwords from database Harm done: can authenticate ○ as any user Done! Mitigation: hashes can’t be ○ Done! reversed SWEN-331: Engineering Secure Software Benjamin S Meyers 12 12
Authentication with Hashes Use case: authenticate ● Bobby Server Database User inputs password ○ login pwd=“xkcd327” Server computes hash ○ Server compares computed ○ Is Bobby hash with stored hash SHA512(“xkcd327”)? Yes! Come on in! SWEN-331: Engineering Secure Software Benjamin S Meyers 13 13
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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 14 14
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) ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 15 15
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! ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 16 16
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) ● SWEN-331: Engineering Secure Software Benjamin S Meyers 17 17
Symmetric vs. Asymmetric Encryption Source: https://www.101computing.net/symmetric-vs-asymmetric-encryption/ SWEN-331: Engineering Secure Software Benjamin S Meyers 18 18
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: E Adam [..] and D Adam [..] ○ Eve’s public and private: E Eve [..] and D Eve [..] ○ 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: D Adam [bubbles]” ○ Sends E Eve [m] to Eve -- only Eve can read the message with D Eve [m] ○ Eve checks E Adam [D Adam [bubbles]]=bubbles to be sure that the message came ○ from Adam SWEN-331: Engineering Secure Software Benjamin S Meyers 19 19
Public/Private Key Encryption Encrypted User 1 Message User 2 Public Key Message Encrypted User 2 Private Key User 2 Message Message SWEN-331: Engineering Secure Software Benjamin S Meyers 20 20
Digital Signing Signed User 1 Message User 1 Private Key Message Signed ‘Validated’ User 1 Public Key User 2 Message Message Validation: ● Message has not been modified ○ Message came from a known sender ○ Message is NOT encrypted ● SWEN-331: Engineering Secure Software Benjamin S Meyers 21 21
Recommend
More recommend
