Jaime Jiménez Bolonio - 1/5

Download as pdf or txt
Download as pdf or txt
You are on page 1of 5

Jaime Jiménez Bolonio - 1/5

INRODUCTION Book: chapter 2

3 types of attacks: ciphertext, known plaintext, chosen plaintext


3 types f cryptographic functions depending on number of keys they use: public key(2),secret key(1),hash(0)
Secret key, with the same key, encrypt and decrypt.
Public key, two keys, private and public. Encrypt and verify with public, decrypt and sign with private.
Public key cryptography (PKC) slower than secret key. PKC used for authentication and to establish temporary
secret key.
PKI is the infrastructure to store public keys on server.
3 Hash properties: easy to compute hash from message, given hash of a message, no way to find the message that
matched the hash, computationally infeasible to find two messages that hash to same string.

SYMMETRIC ENCRYPTION Slides: 02_symmcrypto.ppt, 03_hash.ppt Book: chapters 3,4,5

One-Time Pad random sequence as long as plaintext, as safe as it gets.


RC4, by Ron Rivest, generates a pseudo-random stream. Not so secure.
Substitution cipher: substitutes one thing for another, like monoalphabetic cipher.

Generic Block Encryption: Implements a substitution table, 64b reasonable key and block length.
Substitution: Specifies for each of the possible 2^k input the K output. Impractical for 2^64, ok for 2^8.
Permutation: Specifies for each of the k input bits, the output position where it goes.
Round: Divide block in manageable sizes (8b), substitute each put them together and permutate.

DES: efficient in hardware, slow in software. key 56b. Design not public.
DES round: 64b-> 2*32b(L0 and R0)-> Mangler function on R0 xor with L0 = R1; R0 = L1 .
IDEA: Patented and slow.
AES: Based on Rijndael, block and key size of 128b (although keys of 192 or 256 can also be used)

Encrypting a large message: 2 modes:


• Electronic Code Book (ECB): Dividing message into 64b blocks, then encrypt/decrypt each with secret
key. 3 Flaws: repeated blocks; blocks can be rearranged; no integrity check.
• Cipher Block Chaining (CBC): Same plaintext produces different ciphertext. With IVector. Previous
block of ciphertext as random number (xor with key), no integrity check.
Output Feedback mode (OFB): Stream cipher, creates one-time ad from IV.
Cipher Feedback mode (CFB): Stream cipher, self-synchronizing
Message Authentication Code (MAC): Cryptographic checksum to protect against modifications. In CBC it is the
last block.
Multiple encryption DES: EDE, k1=k2. Any encryption system can be made more secure by using several
encryptions.
Hash: one-way collision resistant function. Message Digest have 128 bits length.
Integrity goal, attacker cannot modify a file without being noticed.
Encryption, provides confidentiality but not necessarily integrity.
Mac with hash, MD(m) not valid since anyone can do it. MD(Kab, m) but anyone can add info at the end.
HMAC: concatenates secret both in front and back.
Keyed hash: any hash combining key and data.
For UNIX passwords we need one-wayness, for integrity of software distribution, collision resistance, for
auction bidding both.
MD5: 128 bit output, Rivest, collision resistance weakness found.
SHA1: 160 bit output, NSA, collision resistance weakness found.
SHA3: 160 bit output, waiting until 2010.

USER AUTHENTICATION Slides: 04_authentication.ppt Book: chapter 10

Ways to prove who you are:


What you know: Passwords, secret key. Salt is a random number stored used to compute hash H(salt, pass), UNIX
uses DES (25 times) as hash function. To avoid offline password guessing 64b (20 digit) enough.
Where you are: IP, but IP is easy to fake and IP is dynamic anyway.
What you are: Biometrics, but computer generated forgery is easy. Hand writing, scanning, both easy to forge.
What you have: Secure tokens. Physical (USB, card...), can be stolen or copied. Smart cards, information
protected by pin.

PUBLIC KEY ENCRYPTION Slides: 05_public.ppt Book: chapter 6

Additive inverse: of x, is the number you'd have to add x to get 0.


Multiplicative inverse: of x, written x^-1 number you'd have to multiply x to get 1.
Totien function: Indicates how many numbers less than n are relatively prime (don't share ¡other common
factors apart from 0) to n. Tot(n)= (p-1)*(q-1), being p, q primes. Also, if y=1 mod Tot(n) , then for any x,
x^y = x mod n
RSA: Public key algorithm for encr and decr, most common length key 512b. Slow, therefore used with the secret
key. Usage:
1. Choose two large prime numbers (256b each), p and q
2. Multiply and obtain n. p*q=n ; Tot(n)=(p-1)*(q-1)
3. Choose another number e, relatively prime to Tot(n)
4. Compute the inverse of e; d = e^-1 mod Tot(n)
5. The Pub key is, <e, n>
6. The Priv key is, <d, n>
7. d*e = 1mod Tot(n)
Encrypt m (<n): c= m^e mod(n)
Decrypt c : m= c^d mod(n)
Sign message : s= m^d mod(n)
Verify sign : m= s^e mod(n)

The real premise behind RSA is that factoring big numbers is hard.
Jaime Jiménez Bolonio - 2/5

Problems generating RSA keys: Hard to find prime numbers, hard to verify large primes.
Threads to RSA: Searching message space, known ciphertext attack (trying all d), cycle attack, low exponent.

PKCS: Standard for infor encrypted with RSA, so that different implementations work.

Diffie-Hellman: Allows strangers to establish secret key over a public (but integrity protected) channel. It
relies on the assumption that finding a discrete logarithm is hard. (INSERT diagram)
Alice Bob
1| <------------we agree on n and g-------------> |
2| --------------Ya=g^x(modn)-------------------> |
3| <-------------Yb=g^y(modn)-------------------- |

Then Alice and Bob compute secret key, K, as K = g^xy (mod n)


Public= n, g, Ya and Yb
Private= Xa, Xb and common secret key K.

Man-in-the-middle Attack: When Alice receives Yb(g^y (modn)), there is no way to be sure it came from Bob.
Defenses against it: Published Diffie-Hellman, Authenticated Diffie-Hellman

The El Gamal signature scheme: Based on the difficulty of computing discrete logarithms. the NIST DSS is based
on it.

EMAIL SECURITY Slides: 14email.ppt Book: chapters 20,21,22

Simple mail transfer protocol (SMTP): Most used standard, port 25. When sending mail to many people it is
common to use distribution lists. remote exploder (send message to DL maintainer, he sends to the receivers),
Local exploder (get list form maintainer and send it yourself to everyone)

Security Services for email: privacy,authentication, integrity, non-repudiation, proof of submission, , proof
of delivery, message flow confidentiality, anonymity, ...
Mail infrastructure consists on a mesh of mail forwarders or Message Transfer Agents (MTA).
Mail Format was simply text, then MIME specified a way to encode arbitrary data on mail, S/MIME tries to
introduce also security.

SPAM
Spoofing: "From" field in the mail can be forged, recipient just sees IP of previous peer.
Open Relay: Forwards mail to destination, a hacked one doesnotshow/changes source IP, so that ISPs don't
blacklist them.
Same with botnets: Spam source has HighSpeed Broadband machine(ThickPipe), Zombie LowSpeed (ThinPipe). the
handshake with the SMTP server is done by LSZ but the spam is sent from the HSB with LSZ address.
Open HTTP proxy: Instead of using web proxy for browsing, you can spam if port 25 is open. SQUID closes 25.
Mail is a one-time activity, difficult to negotiate sec parameters, security depends on clients, info must be
present in the message.

PGP: for encryption and integrity protection on files. Authentication(RSA/SHA), Privacy (Diff-Hell, Gamal...)
Key management: PEM (hierarchy of CAs), PGP (Anarchy), S/MIME (Parallel hierarchy).
PGP uses last 64b of the key as identifier.
Ring of Trust: Signatures have different levels of trust, asserted with the owner of the signature.
S/MIME: key infrastructure of 3 types: public certifier, Organizational Certifier, Incorporating trusted
certificates.

AUTHENTICATION PROTOCOLS AND KEY ESTABLISHMENT Slides: 06_authoprot.ppt Book: chapter 11

Authentication Handshakes: how do you prove to someone that you are who you claim to be?

1.- Send name/password in clear


Problem: Playback attack, someone records it and sends it again.

2.- Send name/encrypted password


Problem: Playback attack

3.- Nonce authentication.


Alice Bob
1| ------------I'm Alice---------------> |
2| <-----------R(nonce)----------------- |
3| ------------Kab(R)------------------> |

Problem: Bob is not authenticated; connection can be hijacked later; offline passwd guessing attack.

4.- Send name/encrypted timestamp (Kab(timestamp)), only Alice knows key to encrypt current time.
Problem: Requires synchronization; in practice needs some time-skew management; Bob not authenticated.

5.- Mutual authentication with symmetric encryption


Alice Bob
1| --------I'm Alice; Ra---------------> |
2| <-------Rb; f(Kab, Ra)--------------- |
3| --------f(Kab, Rb)------------------> |

Problem: Reflection Attack, an attacker opens session and gets Rx in 1, then opens another one and ask to
encrypt Rx in 2 , getting the encrypted Rx in 3.
Jaime Jiménez Bolonio - 3/5

6.- Public key authentication. Bob checks that Ka+(Ka-(R))=R


Alice Bob
1| ------------I'm Alice---------------> |
2| <-----------R------------------------ |
3| ------------Ka-(R)------------------> |

Problem: Sonofabitch-in-the-middle impersonating Alice and Bob; Encryption Tricking.

Trusted Intermediaries:
Symmetric Key Problem:
How do 2 entities establish shared secret key over network? --------> Trusted Key Distribution Center (KDC).
Public Key Problem:
When Alice obtains Bob's public key, how does she know is his? -----> Trusted Certification Authority (CA).

7.- Mediated Authentication (with KDC), used in Kerberos


Alice KDC Bob
1| ----------"I want Bob"-----------> | |
2| <------Kal{use Kab}; TBob---------(*)| |
3| ------------------ "I'm Alice"; TBob--------------------> |
TBob= Kbo(A, Kab) ; Kal = K(a-kdc); Kbo = K(b-kdc); (*) KDC creates Kab

8.- Needham-Schroeder Protocol, completes the exchange doing mutual auth btw Alice and Bob. N is a nonce
(random number used once)
Alice KDC Bob
1| ----------Kal(N1,A,B)-----------------> | |
2| <---------Kal{N,B,Kab,Tbob)------------ | |
3| ------------------ Kbo(A,Kab); Kab(N2)-----------------------> |
4| <----------------- Kab(N2 - 1, N3)---------------------------- |
5| ------------------ Kab(N3-1)---------------------------------> |
TBob= Kbo(A, Kab) ; Kal = K(a-kdc); Kbo = K(b-kdc)
N1 prevents replay attacks; N2, N3 are challenges; 3-4 Bob can decrypt N2=>can decrypt Kab=>knows Kbo=>Is Bob

Problem: Someone may steal Alice's key (Kal) in 2 and use it to communicate with Bob for the rest of the
transaction.
Certification Authority (CA): You give him your pub key + identifying info they give you your pub key signed
by CA. The certificate has serial number, valid dates, owner info and issuer fingerprint. CA does not need to
be online for verification
True randomness expensive, pseudo-randomness is pseudo-security. Nonces are used once, can be timestamps,
sequence numbers (both attackable by guessing) or large random numbers.

PKI AND WEB SECURITY Slides: 08_pki.ppt, 11_tls.ppt, 09_web.ppt Book: chapters 9,19,25, PKI=15

PKI: consists on certificates, repository for retrieving them, revocation, certificate chain and evaluation.
One CA for everyone is impractical, PKI arises to organize.
Hierarchical approach: Root authority (Verisign), signing smaller authorities, signing ... = certificate
chain.
3 trust models: Monopoly (single CA, risky, usually with other RAs or delegated CAs), Oligarchy (many CAs
preinstalled, easy to trick users to trust certificates), Anarchy (PGP web of trust).
PKIX specifies which X.509 option to use. Choosing X.509 for certificate formats = bad decision. Few apps use
X.500 names.
4 reasons to revocate certificate: compromised key, expiration, user does not pay, compromised CA.
2 mechanisms of revocating them: online revocation service, Certification Revocation List (CRL).

SSL runs on top of TCP, protects against application level threads, not IP ones.
TLS consists of two protocols: Handshake Protocol (Pub Key to establish shared/master key) and Record Protocol
(secret key to protect communications)
Version number is incorrectly specified and not integrity protected, can be changed to trick machine and end
connection.
In SSLv2 Alice sends list f possible ciphersuites, Bob picks and Alice makes final decision.
In SSLv3, Bob just decides. SSLv3 includes "finished" messages.
3 Attacks: Downgrade Attack (no integrity protection, attacker can remove best ciphersuites from the list
Alice sends), Truncation Attack (Attacker can close connection), Version Rollback Attack (v2 instead of v3).
Jaime Jiménez Bolonio - 4/5

IPSEC AND IKE Slides: 09_ipsec.ppt, 10_ike.ppt Book: chapters 16,17,18

IPSEC, framework of open standards for secure communications over IP.


|App| User SSL changes API to TCP/IP, apps change but OS doesn't
----------------------- Socket API
|TCP| OS IPsec in OS, apps don't change (theoretically...)
|IP |
----------------------- Device Driver
|L2 | Interface
|L1 |

IPsec = (AH + ESP) + IKE


IKE sets up keys and algorithms for AH and ESP, AH and ESP protect IP traffic.
AH provides connectionless integrity and data origin authentication. Header protected (not mutable fields like
ttl, checksum ...)
ESP provides origin authenticity, integrity, and confidentiality protection. Header protected only in Tunnel
mode.
2 ESP modes:
Transport mode: for host-to-host/gateway services; |IPheader|IPsec|Rest| ; IPheader unchanged.
Tunnel mode: for gateway-to-gateway services; |NewIPheader|IPsec|IPheader|Rest|; Used on VPNs

Security Association (SA): SA is a cryptographycally protected connection. unidirectional, a conversation


between Alice and Bob would imply 2 SA. SA = {SecParamIndec, dest IP, flag(ESP or AH)}

Internet Key Exchange (IKE): Protocol used to set up a SA in IPsec. Uses Diffie-Hellman. It's crap and it even
uses UDP!
IKE Phase1: To establish a secure channel using D-H. Authentication can be performed either with
preshared/shared/public keys. Phase 1 has two modes (protects peer identity), main and aggresive.
IKE Phase2: Uses the secure channel of phase 1 to negotiate the SA on behalf of IPsec. Operates in Quick mode
(whatever that is).

FIREWALLS Slides: 13_firewalls.ppt Book: chapter 23

Firewall: filters packets.


3 design goals: Traffic must pas through it; only authorised traffic can pass; the firewall itself should be
immune to penetration.
4 types of control: Service (packet filtering...), Direction, User (access to service), Behaviour.
3 locations: Between LAN and external network, At the network gateways, on end user machines.
2 types:
• Packet filters: decision per packet, depending on (ip, dest, TCP flags...). 2 policies, discard (more
conservative) and forward. Weaknesses: useless against app specific attacks, no user-authentication mechanism,
vulnerable to spoofing. Statefull packet filter: maintains a record of all connections passing through, and
can determine whether a connection is part of and old one.
• Application Level Gateway: usually placed btw two firewalls (DMZ), this configuration named "bastion
host".
Problems with firewalls: interfere with networked apps; assume that users inside the network are trusted;
misconfiguration and increased complexity.

KERBEROS Slides: 07_kerberos.ppt Book: chapter 13

Many-to-many How to authenticate users that connect to different machines (many-to-many)? it has to be
scalable, secure and transparent to users.
5 Threats: user impersonation, network address impersonation, eavesdropping, tampering and replay.

Many-to-many trusted third party


Use symmetric key authentication, get ticket from third party. Possible point of failure, auth server.
Ticket: proof of authorization an authentication, must not be reusable many times. Created with the server's
key. Ticket Granting Ticket (TGT) Works like a login cookie, typically last for a day (long term). TGT done by
authentication server.

a)Obtaining Session Key and TGT. Requested once


Alice Workstation KDC
1| ---plaintxt(Alice, password)----------> | ----------Alice needs TGT-----------> (*)|
2| | <---------Ka {Sa, TGT}--------------- |
(*) invents key Sa (secret key for session), finds Alice's master key Ka; TGT = Kkdc{"Alice",Sa}

b)Getting ticket for Bob (printer,...) for Alice. Requested once per service
Alice Workstation KDC
1| ----------rlogin Bob------------------> | ------TGT = Kkdc{"Alice",Sa}; Sa(timestamp)-------> (*)|
2| | <---------Sa{"Bob",Kab,Ticket2Bob}----------------- |
(*) invents key Kab, decrypts TGT to get Sa, decrypts authenticator (Sa), verifies timestamp, finds Bob's
master key Kb; Ticket2Bob={"Alice",Kab}

c)Logging into Bob (printer,...) from Alice's workstation, once per service session
Workstation KDC
1| ------Ticket2Bob; Kab(timestamp)-------> (*)|
2| <-----Kab(timestamp+1)------------------ |
(*)decrypts ticket to get Kab, decrypts Kab, verifies timestamp.

Longterm keys: Kc(client), Ktgs, Kv(network service), Kc-kdc (TGT).


Shorterm keys: Kc-tgs, Kc-v
Jaime Jiménez Bolonio - 5/5

Ideas of Kerberos: Use of short-term session keys, proofs of identity are based on authenticators, server
learns key via encrypted key, not directly. No public key (no RSA, no D-H) only symmetric Cryptography.

Realms: To use services in different places (realms). You need: TGT from home KDC, ticket for remote realm TGS
from home realm TGS (as if it was any other service), use remote realm as normal TGS from home realm.
Principal: Id, entry in authentication database.
Credential cache: where tickets and sessions are stored.

You might also like