Jaime Jiménez Bolonio - 1/5
Jaime Jiménez Bolonio - 1/5
Jaime Jiménez Bolonio - 1/5
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)
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)-------------------- |
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.
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 Handshakes: how do you prove to someone that you are who you claim to be?
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.
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
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).
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
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).
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.
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.
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.