Encryption and Security Tutorial

Peter Gutmann University of Auckland

Security Requirements
• Protection from disclosure to unauthorised persons

• Maintaining data consistency

• Assurance of identity of person or originator of data

• Originator of communications can’t deny it later

Security Requirements (ctd)
• Legitimate users have access when they need it

Access control
• Unauthorised users are kept out

These are often combined
• User authentication used for access control purposes • Non-repudiation combined with authentication

Security Threats
Information disclosure/information leakage Integrity violation Masquerading Denial of service Illegitimate use Generic threat: Backdoors, trojan horses, insider attacks Most Internet security problems are access control or authentication ones
• Denial of service is also popular, but mostly an annoyance

Attack Types

Passive attack can only observe communications or data Active attack can actively modify communications or data
• Often difficult to perform, but very powerful – Mail forgery/modification – TCP/IP spoofing/session hijacking

Security Services
From the OSI definition:
• Access control: Protects against unauthorised use • Authentication: Provides assurance of someone's identity • Confidentiality: Protects against disclosure to unauthorised identities • Integrity: Protects from unauthorised data alteration • Non-repudiation: Protects against originator of communications later denying it

Security Mechanisms
Three basic building blocks are used:
• Encryption is used to provide confidentiality, can provide authentication and integrity protection • Digital signatures are used to provide authentication, integrity protection, and non-repudiation • Checksums/hash algorithms are used to provide integrity protection, can provide authentication

One or more security mechanisms are combined to provide a security service

Services, Mechanisms, Algorithms
A typical security protocol provides one or more services

• Services are built from mechanisms • Mechanisms are implemented using algorithms

Conventional Encryption
Uses a shared key

Problem of communicating a large message in secret reduced to communicating a small key in secret

Public-key Encryption
Uses matched public/private key pairs

Anyone can encrypt with the public key, only one person can decrypt with the private key

Key Agreement
Allows two parties to agree on a shared key

Provides part of the required secure channel for exchanging a conventional encryption key

Hash Functions
Creates a unique “fingerprint” for a message

Anyone can alter the data and calculate a new hash value
• Hash has to be protected in some way

Message Authentication Code, adds a password/key to a hash

Only the password holder(s) can generate the MAC

Digital Signatures
Combines a hash with a digital signature algorithm

Digital Signatures (ctd) Signature checking: Message/Data Encryption Combines conventional and public-key encryption .

the more transparent it is The further up you go. the easier it is to deploy .Message/data Encryption (ctd) Public-key encryption provides a secure channel to exchange conventional encryption keys Security Protocol Layers The further down you go.

1900BC Atbash cipher (Old Testament. reversed Hebrew alphabet.Encryption and Authentication Algorithms and Technology Cryptography is nothing more than a mathematical framework for discussing the implications of various paranoid delusions — Don Alvarez Historical Ciphers Non-standard hieroglyphics. 600BC) Caesar cipher: letter = letter + 3 ‘fish’  ‘ilvk’ rot13: Add 13/swap alphabet halves • Usenet convention used to hide possibly offensive jokes • Applying it twice restores original text .

Break by decomposing into individual alphabets.g. b = m.. c = p.. radioactive decay) . c = f. . b = t.. Break via letter frequency analysis Polyalphabetic substitution cipher 1. a = l. then solve as simple substitution One-time Pad (1917) Message OTP s 18 +15 e 5 8 c r 3 17 4 d e t 5 19 5 1 12 19 7 13 g m 3 24 24 c x x OTP is unbreakable provided • Pad is never reused (VENONA) • Unpredictable random numbers are used (physical sources. c = f.. 3. e. c = a. . . a = f. 2. b = m.. .. b = x.. a = p.Substitution Ciphers Simple substitution cipher: a = p..

Basic component = wired rotor • Simple substitution 2. first mechanically. period = 26 . then electronically Cipher Machines (~1920) 1. Step the rotor after each letter • Polyalphabetic substitution.One-time Pad (ctd) Used by • Russian spies • The Washington-Moscow “hot line” • CIA covert operations Many snake oil algorithms claim unbreakability by claiming to be a OTP • Pseudo-OTP’s give pseudo-security Cipher machines attempted to create approximations to OTP’s.

Chain multiple rotors Each steps the next one when a full turn is complete Cipher Machines (ctd) Two rotors.576 Rotor sizes are chosen to be relatively prime to give maximum-length sequence Key = rotor wiring = rotor start position .Cipher Machines (ctd) 3. period = 26  26 = 676 Three rotors. period = 26  26  26 = 17.

Purple Germany: Enigma Many books on Enigma Kahn.. The Hut Six Story Winterbothm. a mistake still made today Inventors believed it was infallible. " " " " " .. Seizing the Enigma Levin.Cipher Machines (ctd) Famous rotor machines US: Converter M-209 UK: TYPEX Japan: Red.” “Nothing to report” Use of the same key over an extended period Encryption of the same message with old (compromised) and new keys Device treated as a magic black box. The Ultra Secret “It would have been secure if used properly” Use of predictable openings: “Mein Fuehrer! . Ultra Goes to War Welchman.

quarterly journal Stream Ciphers Binary pad (keystream).Cipher Machines (ctd) Various kludges made to try to improve security — none worked Enigmas were sold to friendly nations after the war Improved rotor machines were used into the 70’s and 80’s Further reading: Kahn. unencrypted data Ciphertext = encrypted data Plaintext 1 Keystream XOR 0 Ciphertext 1 Keystream XOR 0 Plaintext 1 0 1 1 1 0 0 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1 0 1 0 1 1 1 0 1 1 Two XORs with the same data always cancel out . The Codebreakers Cryptologia. use XOR instead of addition Plaintext = original.

we can recover the keystream Using two ciphertexts from the same keystream. never use a stream cipher Stream Ciphers (ctd) Vulnerable to bit-flipping attacks . we can recover the XOR of the plaintexts • Any two components of an XOR-based encryption will recover the third • Never reuse a key with a stream cipher • Better still. we can recover the plaintext but Using the plaintext and ciphertext.Stream Ciphers (ctd) Using the keystream and ciphertext.

y += sx. . state[ x ] = sy. Windows server authentication.) { x++. reverse-engineered and posted to the net in 1994 while( length-. sx = state[ x ]..RC4 Stream cipher optimised for fast software implementation 2048-bit key.. Windows NT SYSKEY.. Oracle Secure SQL. • Usually used in a manner which allows the keystream to be recovered (Windows password encryption. Adobe Acrobat. Windows password encryption. MS PPTP. MSIE). early Netscape server key encryption. MS PPTP. MS Access. *data++ ^= state[ ( sx+sy ) & 0xFF ].. 8-bit output Former trade secret of RSADSI. sy = state[ y ].) • Every MS product which is known to use it has got it wrong at some time Illustrates the problem of treating a cipher as a magic black box Recommendation: Avoid this. . MS Access. some MS server/browser key encryption. } Takes about a minute to implement from memory RC4 (ctd) Extremely fast Used in SSL (Netscape. it's too easy to get wrong . Lotus Notes. state[ y ] = sx.

the greater the security (to a point) Most famous example of this design is DES: • 16 rounds • 56 bit key • 64 bit block size (L. the more rounds. doesn’t have to be reversible Each step is called a round. uh.Block Ciphers Originated with early 1970’s IBM effort to develop banking security systems First result was Lucifer. most common variant has 128-bit key and block size • It wasn’t secure in any of its variants Called a Feistel or product cipher Block Ciphers (ctd) f()-function is a simple transformation. advice from the NSA .R = 32 bits) Designed by IBM with.

virtually all block ciphers from before that time are vulnerable. IBM (and the NSA) knew about it 15 years earlier Strength of DES Key size = 56 bits Brute force = 255 attempts Differential cryptanalysis = 247 attempts Linear cryptanalysis = 243 attempts (but the last two are impractical) > 56 bit keys don’t make it any stronger > 16 rounds don’t make it any stronger ...Attacking Feistel Ciphers Differential cryptanalysis • Looks for correlations in f()-function input and output Linear cryptanalysis • Looks for correlations between key and cipher input and output Related-key cryptanalysis • Looks for correlations between key changes and cipher input/output Differential cryptanalysis discovered in 1990. ..except DES..

DES Key Problems Key size = 56 bits = 8  7-bit ASCII chars Alphanumeric-only password converted to uppercase = 8  ~5-bit chars = 40 bits DES uses low bit in each byte for parity = 32 bits • Forgetting about the parity bits is so common that the NSA probably designs its keysearch machines to accommodate this Breaking DES DES was designed for efficiency in early-70’s hardware Makes it easy to build pipelined brute-force breakers in late-90’s hardware 16 stages. tests 1 key per clock cycle .

net = ~70 billion keys/sec with 20. softwareprogrammable hardware • Application-specific IC (ASIC) 100 MHz ASIC = 100M keys per second per chip Chips = $10 in 5K+ quantities $50. don’t encrypt it with DES September 1998: German court rules DES “out of date and unsafe” for financial applications .000 computers) EFF (US non-profit organisation) broke DES in 2½ days Amortised cost over 3 years = 8 cents per key • If your secret is worth more than 8 cents.Breaking DES (ctd) Can build a DES-breaker using • Field-programmable gate array (FPGA).000 = 500 billion keys/sec = 20 hours/key (40-bit DES takes 1 second) Breaking DES (ctd) $1M = 1 hour per key (1/20 sec for 40 bits) $10M = 6 minutes per key (1/200 sec for 40 bits) (US black budget is ~$25-30 billion) (distributed.

7 secs 13 hours 70 $0. 1024 bit key • RSADSI trade secret.000 12 mins 556 days 55 $0.08 $5.000 24 secs 19 days 60 $0.000 0.005 s 6 mins $0.001 $38 84 89 Other Block Ciphers Triple DES (3DES) • Encrypt + decrypt + encrypt with 2 (112 bits) or 3 (168 bits) DES keys • By late 1998.08 $5. banking auditors were requiring the use of 3DES rather than DES RC2 • Companion to RC4.000 0. reverse-engineered and posted to the net in 1996 • RC2 and RC4 have special status for US exportability .0002 s 12 secs 75 $0.08 $5.18 secs 3 hours $0.001 $38 0.001 $38 0.08 $5.Brute-force Encryption Breaking Type of Attacker Pedestrian hacker Small business Corporate department Budget Tool Time and cost per key recovered Keylen (bits) for security 2015 59 64 69 74 Tiny $400 $10K $300K PC FPGA FPGA FPGA ASIC Big company $10M FPGA ASIC Intelligence $300M ASIC agency 40 bits 56 bits 1995 1 week Infeasible 45 5 hours 38 years 50 $0.

128 bit key Other Block Ciphers Skipjack • Classified algorithm originally designed for Clipper. smart cards) • 32 rounds. adapted to resist differential cryptanalysis as IPES. breakable with 31 rounds • 80 bit key.Other Block Ciphers (ctd) IDEA • Developed as PES (proposed encryption standard). Russian answer to DES • 32 rounds. relatively slow key setup CAST-128 • Used in PGP 5. 256 bit key • Incompletely specified .x. 128 bit key • Patented Blowfish • Optimised for high-speed execution on 32-bit processors • 448 bit key. inadequate for long-term security GOST • GOST 28147. declassified in 1998 • Very efficient to implement using minimal resources (e. then IDEA • Gained popularity via PGP.g.

proven algorithms Using Block Ciphers ECB. 128/192/256 bit key Many. Electronic Codebook Each block encrypted independently .Other Block Ciphers AES • Advanced Encryption Standard. many others • No good reason not to use one of the above. replacement for DES • 128 bit block size.

number 12-3456.789012-3 Intercepted encrypted form H2nx/GHE KgvldSbq GQHbrUt5 tYf6K7ug S4CrMTvH 7eMPZcE2 Second intercepted message H2nx/GHE KgvldSbq GQHbrUt5 tYf6K7ug Pts21LGb a8oaNWpj Cut and paste blocks with account information H2nx/GHE KgvldSbq GQHbrUt5 tYf6K7ug S4CrMTvH a8oaNWpj Decrypted message will contain the attacker’s account — without them knowing the encryption key Using Block Ciphers (ctd) Need to • Chain one block to the next to avoid cut & paste attacks • Randomise the initial block to disguise repeated messages CBC (cipher block chaining) provides chaining.Using Block Ciphers (ctd) Original text Deposit $10. random initialisation vector (IV) provides randomisation .000 in acct.

CAST-128. AES Skipjack DES.Using Block Ciphers (ctd) Both ECB and CBC operate on entire blocks CFB (ciphertext feedback) operates on bytes or bits This converts a block cipher to a stream cipher (with the accompanying vulnerabilities) Relative Performance Fast RC4 Blowfish. RC2 3DES. use Blowfish • For job security. use 3DES . IDEA. GOST Slow Typical speeds • RC4 = Tens of MB/second • 3DES = MB/second Recommendations • For performance.

key2 = 1/3. one is kept private  public-key cryptography. message M = 4 Encryption: Ciphertext C = M  key1 =43 = 12 Decryption: Plaintext M = C  key2 = 12  1/3 =4 One key is published.Public Key Encryption How can you use two different keys? • One is the inverse of the other: key1 = 3. q = 5. e = public key. n = product of two primes p and q d = private key Encryption: C = Me mod n Decryption: M = Cd mod n p. 7 n=pq = 35 e=5 d = e-1 mod ((p-1)(q-1)) =5 . PKC Example: RSA n.

1977 • Digital signatures and encryption in one algorithm • Private key = sign and decrypt • Public key = signature check and encrypt DH (Diffie-Hellman). one algorithm for encryption. 1976 • Key exchange algorithm Elgamal • DH variant.Example: RSA (ctd) Message M = 4 Encryption: C = 45 mod 35 =9 Decryption: M = 95 mod 35 = 59049 mod 35 =4 (Use mathematical tricks otherwise the numbers get dangerous) Public-key Algorithms RSA (Rivest-Shamir-Adelman). one for signatures • Attractive as a non-patented alternative to RSA (before the RSA patent expired) .

designed by the NSA as the US government digital signature standard • Intended for signatures only. but can be adapted for encryption All have roughly the same strength: 512 bit key is marginal 1024 bit key is recommended minimum size 2048 bit key is better for long-term security Recommendation • Anything suitable will do • RSA has universal acceptance. others are less accepted Elliptic Curve Algorithms Use mathematical trickery to speed up public-key operations .Public-key Algorithms (ctd) DSA (Digital Signature Algorithm) • Elgamal signature variant.

Elliptic Curve Algorithms (ctd) Now we can add. pending patents. So what? • Breaking PKCs over elliptic curve groups is much harder than beaking conventional PKCs • We can use shorter keys which consume less storage space Advantages/Disadvantages of ECC’s Advantages • Sometimes useful in smart cards because of their low storage requirements Disadvantages • New. and submarine patents Recommendation: Don’t use them unless you really need the small key size . So what? • Calling it “addition” is arbitrary. details are still being resolved – Many ECC techniques are still too new to trust • Almost nothing uses or supports them • No more efficient than standard algorithms like RSA • ECCs are a minefield of patents. we can just as easily call it multiplication • We can now move (some) conventional PKCs over to EC PKCs (DSA  ECDSA) Now we have a funny way to do PKCs. etc. subtract.

attacker can – Delete your files • Compromised private key. attacker can – Drain credit card – Clean out bank account – Sign contracts/documents – Identity theft .Key Sizes and Algorithms Conventional vs public-key vs ECC key sizes Conventional (40 bits) 56 bits 64 bits 80 bits 90 bits 112 bits 120 bits 128 bits Public-key — (400 bits) 512 bits 768 bits 1024 bits 1792 bits 2048 bits 2304 bits ECC — — — — 160 bits 195 bits 210 bits 256 bits (Your mileage may vary) Key Sizes and Algorithms (ctd) However • Conventional key is used once per message • Public key is used for hundreds or thousands of messages A public key compromise is much more serious than a conventional key compromise • Compromised logon password.

long-term secrets The same holds for equivalent-level conventional and ECC keys Hash Algorithms Reduce variable-length input to fixed-length (128 or 160 bit) output Requirements • Can’t deduce input from output • Can’t generate a given output (CRC fails this requirement) • Can’t find two inputs which produce the same output (CRC also fails this requirement) Used to • Produce fixed-length fingerprint of arbitrary-length data • Produce data checksums to enable detection of modifications • Distil passwords down to fixed-length encryption keys Also called message digests or fingerprints .5K bit key for longer-term use Use 2K bit key for certification authorities (keys become more valuable further up the hierarchy).Key Sizes and Algorithms (ctd) 512 bit public key vs 40 bit conventional key is a good balance for weak security Recommendations for public keys: • • • • Use 512-bit keys only for micropayments/smart cards Use 1K bit key for short-term use (1 year expiry) Use 1. long-term contract signing.

weaknesses SHA-1: 160-bit output. deprecated MD4: 128-bit output. companion to DSA RIPEMD-160: 160-bit output HMAC-MD5: MD5 turned into a MAC HMAC-SHA: SHA-1 turned into a MAC Recommendation: Use SHA-1.MAC Algorithms Hash algorithm + key to make hash value dependant on the key Most common form is HMAC (hash MAC) hash( key. NSA-designed US government secure hash algorithm. hash( key. HMAC-SHA . broken MD5: 128-bit output. data )) • Key affects both start and end of hashing process Naming: hash + key = HMAC-hash MD5  HMAC-MD5 SHA  HMAC-SHA Algorithms MD2: 128-bit output.

What RSA has joined. let no man put asunder — Bob Blakley Key Management Key management is the hardest part of cryptography Two classes of keys • Short-term session keys (sometimes called ephemeral keys) – Generated automatically and invisibly – Used for one message or session and discarded • Long-term keys – Generated explicitly by the user Long-term keys are used for two purposes • Authentication (including access control. and nonrepudiation) • Confidentiality (encryption) – Establish session keys – Protect stored data . integrity.Key Management and Certificates By the power vested in me I now declare this text and this bit string ‘name’ and ‘key’.

Key Management Problems Key certification Distributing keys • Obtaining someone else’s public key • Distributing your own public key Establishing a shared key with another party • Confidentiality: Is it really known only to the other party? • Authentication: Is it really shared with the intended party? Key storage • Secure storage of keys Revocation • Revoking published keys • Determining whether a published key is still valid Key Lifetimes and Key Compromise Authentication keys • Public keys may have an extremely long lifetime (decades) • Private keys/conventional keys have shorter lifetimes (a year or two) Confidentiality keys • Should have as short a lifetime as possible If the key is compromised • Revoke the key Effects of compromise • Authentication: Signed documents are rendered invalid unless timestamped • Confidentiality: All data encrypted with it is compromised .

Key Distribution Alice retains the private key and sends the public key to Bob Mallet intercepts the key and substitutes his own key Mallet can decrypt all traffic and generate fake signed message Key Distribution (ctd) A certification authority (CA) solves this problem CA signs Alice’s key to guarantee its authenticity to Bob • Mallet can’t substitute his key since the CA won’t sign it .

Certification Authorities A certification authority (CA) guarantees the connection between a key and an end entity An end entity is • • • • • • A person A role (“Director of marketing”) An organisation A pseudonym A piece of hardware or software An account (bank or credit card) Some CA’s only allow a subset of these types Obtaining a Certificate .

ID.Obtaining a Certificate (ctd) 1. creating a certificate • CA has certified the binding between the key and ID 4. Optional: CA verifies Alice’s ID through out-of-band means • email/phone callback • Business/credit bureau records. Alice verifies the key. CA signs the public key and ID with the CA key. CA verifies Alice’s signature on the key and ID information 2a. and CA’s signature • Ensures the CA didn’t alter the key or ID • Protects the certificate in transit 5. Alice and/or the CA publish the certificate . in-house records Obtaining a Certificate (ctd) 3. Alice generates a key pair and signs the public key and identification information with the private key • Proves that Alice holds the private key corresponding to the public key • Protects the public key and ID information while in transit to the CA 2.

Role of a CA Original intent was to certify that a key really did belong to a given party Role was later expanded to certify all sorts of other things • • • • • Are they a bona fide business? Can you trust their web server? Can you trust the code they write? Is their account in good standing? Are they over 18? When you have a certificate-shaped hammer. global directory run by monopoly telcos . it’s necessary to understand the history behind it Original 1970s research work saw certificates as a one-time assertion about public keys • “This key is valid at this instant for this person” • Never put into practice Certificates in practice were applied to protect access to the X.500 directory • All-encompassing.509 PKI. everything looks like a nail Certificate History To understand the X.

Certificate History (ctd) Concerns about misuse of the directory • Companies don’t like making their internal structure public – Directory for corporate headhunters • Privacy concerns – Directory of single women – Directory of teenage children X. no concept of CAs. etc X.509 certificates were developed as part of the directory access control mechanisms • Acted as an RSA analog to a password • Strictly a password replacement. key usage. a guaranteed unique name for everything on earth .500 Naming X.500 introduced the Distinguished Name (DN).

500 Naming (ctd) Typical DN components • • • • • • Country C State or province SP Locality L Organisation O Organisational unit OU Common name CN Typical X.X.500 Names No-one ever managed to figure out how to make DN’s work This is a real diagram taken from X.500 Standards Designers/CN=John Doe – When the X. your name will be lined up against the wall and shot Problems with X.500 revolution comes.500 DN C=US/L=Area 51/O=Hanger 18/OU=X.521 .

Problems with X.500 Names (ctd) No clear plan on how to organise the hierarchy • Attempts were made to define naming schemes. boarding schools) Nomadic peoples Merchant ships Quasi-permanent non-continental structures (oil towers) US APO addresses LA phone directory contains > 1.000 people called “Smith” in a nonexistant 90000 area code – A bogus address is cheaper than an unlisted number – Same thing will happen on a much larger scale if people are forced to provide information (cf cypherpunks login) . but nothing really worked • People couldn’t even agree on what things like ‘localities’ were Hierarchical naming model fits the military and governments. but doesn’t work for businesses or individuals Problems with X.500 Names (ctd) DNs provide the illusion of order while preserving everone’s God-given Freedom to Build a Muddle Simple problem cases • • • • • • Communal living (jails.

SP.500 Names (ctd) For a corporation. is C.Problems with X. L • Place of birth? • Place of residence/domicile? – Dual citizenship – Stateless persons – Nomads • Place of work? Solution: Specify it in the CPS. L • • • • Location of company? Location of parent company? Location of field office? Location of incorporation? For a person. SP. which noone reads anyway DNs in Practice Public CAs typically set C = CA country O = CA name OU = Certificate type/class CN = User name email = User email address • Some European CAs add oddball components required by local signature laws • Some CAs modify the DN with a nonce to try and guarantee uniqueness . is C.

CN } be set • Resulting certificates contain strange or meaningless entries as people try and guess values. X. or use dummy values • Windows 2000 has given up on issuer  subject chaining by names entirely and instead chains by hash of the public key Solving the DN Problem Two solutions were informally adopted 1. L. SP. Users put whatever they felt like into the DN 2. OU.509v3 added support for alternative (non-DN) names – These are largely ignored in favour of the DN though General layout for a business-use DN Country + Organisation + Organisational Unit + Common Name – C=New Zealand O=Dave’s Wetaburgers OU=Procurement CN=Dave Taylor . O.DNs in Practice (ctd) Private CAs (organisations or people signing their own certs) typically set any DN fields supported by their software to whatever makes sense for them • Some software requires that all of { C.

Solving the DN Problem (ctd) General layout for a personal-use DN Country + State or Province + Locality + Common Name – C=US SP=California L=San Francisco CN=John Doe There are dozens of other odd things which can be specified • teletexTerminalIdentifier • destinationIndicator • supportedApplicationContext Luckily these are almost never used Non-DN Names X. email addresses are often stuffed into DN’s rather than being specified as actual email addresses .509 v3 added support for other name forms • • • • • • email addresses DNS names URL’s IP addresses EDI and X.400 names Anything else (type+value pairs) For historical reasons.

Problems with Naming/Identity Certificates “The user looks up John Smith’s certificate in a directory” • Which directory? • Which John Smith? X. biometric information. jurisdiction where certificate is valid. middle.509-style PKI turns a key distribution problem into a name distribution problem • Cases where multiple people in same O. etc • Qualified certificates only apply to natural persons Some jurisdictions don’t allow this type of unique personal identifier • Any government that can issue this type of identifier can create unpersons by refusing to issue it . OU have same first. and last name • Solve by adding some distinguishing value to DN (eg part of SSN) – Creates unique DNs. but they’re useless for name lookups – John Smith 8721 vs John Smith 1826 vs John Smith 3504 Qualified Certificates Certificate designed to identify a person with a high level of assurance Precisely defines identification information in order to identify the cert owner in a standardised manner • Defines additional parameters such as key usage.

so some approximation to a CN must be supplied even if a pseudonym is used Defines personalData. not DN) name.500 Directory The directory contains multiple objects in object classes defined by schemas A schema defines • Required attributes • Optional attributes • The parent class Attributes are type-andvalue pairs Attribute Object Attribute Attribute Value Value Value • Type = DN. gender – Date and place of birth – Country of residence and/or citizenship – Postal address The X. ie can be mapped to a real name via an external lookup • Most implementations assume every DN contains a CN. a new subjectAltName subtype • Registration authority for personal data information • Collection of personal data – Full (real.Qualified Certificates (ctd) Allows use of a pseudonym • Pseudonym must be registered. value = John Doe • Type may have multiple values associated with it • Collective attributes are attributes shared across multiple entries (eg a company-wide fax number) .

500 Directory (ctd) Data is accessed by DN and attribute type .500 Directory (ctd) Each instantiation of an object is a directory entry Entries are identified by DN’s • The DN is comprised of relative distinguished names (RDN’s) which define the path through the directory Directory entries may have aliases which point to the actual entry The entry contains one or more attributes which contain the actual data The X.The X.

Searching the Directory Searching is performed by subtree refinement • Base specifies where the start in the subtree • Chop specifies how much of the subtree to search • Filter specifies the object class to filter on Example • Base = C=NZ • Chop = 1 RDN down from the base • Filter = organisation Typical application is to populate a tree control for directory browsing • SELECT name WHERE O=* Directory Implementation The directory is implemented using directory service agents (DSA’s) Users access the directory via a directory user agent (DUA) • Access requests may be satisfied through referrals or chaining One or more DSA’s are incorporated into a management domain .

500 Directory Access Protocol (DAP) adapted for Internet use • Designed to allow account name + password access on a ‘286 PC running DOS • Originally Lightweight Directory Access Protocol. delete to update entries search. now closer to HDAP Provides access to LDAP servers (and hence DSAs) over a TCP/IP connection • • • • bind and unbind to connect/disconnect read to retrieve data add. compare to locate information . modify.Directory Access Typical directory accesses: • • • • Read attribute or attributes from an entry Compare supplied value with an attribute of an entry List DN’s of subordinate entries Search entries using a filter – Filter contains one or more matching rules to apply to attributes – Search returns attribute or attributes which pass the filter Add a new leaf entry Remove a leaf entry Modify an entry by adding or removing attributes Move an entry by modifying its DN • • • • LDAP X.

keys are stored in • • • • • Flat files (one per key) Berkeley DB Relational databases Proprietary databases (Netscape) Windows registry (MSIE) Pragmatic solution uses a conventional RDBMS • Already exists in virtually all corporates • Tied into the existing corporate infrastructure • Amenable to key storage – SELECT key WHERE name=‘John Doe’ – SELECT key WHERE expiryDate < today + 1 week . We have a pilot with 200 users running already” Most practical way to use it is as a simple database SELECT key WHERE name=‘John Doe’ Key Databases/Directories Today.LDAP (ctd) LDAP provides a complex hierarchical directory containing information categories with sub-categories containing nested object classes containing entries with one or more (usually more) attributes containing actual values • In one large-scale interop test the use of a directory for cert storage was found to be the single largest cause of problems Simplicity made complex “It will scale up into the billions.

500 hierarchy have CAs attached to them RD N O=University of Auckland Organisational CA DN N RD OU=Computer Science Departmental CA RD N CN=end user Top-level CA is called the root CA.CA Hierarchy in Theory Portions of the X. aka “the single point of failure” CA Hierarchy in Practice Flat or Clayton’s hierarchy CA certificates are hard-coded into web browsers or email software • Later software added the ability to add new CAs to the hardcoded initial set .

re-parenting. revocation and re-issuance/ replacement. the hierarchy of trust… . many flat hierarchies • Every CA has a set of root certificates used to sign other certificates in relatively flat trees What happens when you’re in hierarchy A and your trading partner is in hierarchy B? Solution: CAs cross-certify each other • A signs B’s certificate • B signs A’s certificate Cross-Certification (ctd) Problem: Each certificate now has two issuers • All of X. subordination of one CA to another.500-based scheme envisaged a strict hierarchy rooted at the directory root • PEM tried (and failed) to apply this to the Internet Later work had large numbers of hierarchies • Many. I don’t think we’re in X.509 is based on the fact that there’s a unique issuer • Toto.Cross-Certification Original X.509 any more With further cross-certification.

etc etc • Certificate paths can contain loops • Certificate semantics can change on different iterations through the loop • Are certificate paths Turing-complete? • No software in existence can handle these situations Cross-certification is the black hole of PKI • All existing laws break down • Noone knows what it’s like on the other side . constraints.Cross-Certification (ctd) …becomes the spaghetti of doubt… …with multiple certificate paths possible Cross-Certification (ctd) Different CAs and paths have different validity periods.

they will build it • Allow cross-certification and it’s only a matter of time before the situation will collapse into chaos • c.509 Bridge CAs Attempt to solve the cross-certification chaos by unifying disparate PKIs with a super-root Bridge CA Still has problems • PKIn root has different semantics than bridge root • What if PKI1 = CIA. PKI3 = Mossad? – Trust issues are discussed elsewhere .Cross-Certification (ctd) The theory: A well-managed PKI will never end up like this The practice: If you give them the means. PKI2 = KGB.f. CA vs EE certificates – There are at least 5 different ways to differentiate the two – Only one of these was ever envisaged by X.

a form of anti-certificate which cancels a certificate • Equivalent to 1970s-era credit card blacklist booklets • Relying parties are expected to check CRLs before using a certificate – “This certificate is valid unless you hear somewhere that it isn’t” .509 Certificate Usage Model Relying party wants to verify a signature • Fetch certificate • Fetch certificate revocation list (CRL) • Check certificate against CRL • Check signature using certificate tch Fe Fet ch Cert Check Check CRL Signature Certificate Revocation Revocation is managed with a certificate revocation list (CRL).X.

CRL Problems CRLs don’t work • Violate the cardinal rule of data-driven programming “Once you have emitted a datum you can’t take it back” • In transaction processing terms. viewing a certificate as a PREPARE and a revocation as a COMMIT – No action can be taken between the two without destroying the ACID properties of the transaction – Allowing for other operations between PREPARE and COMMIT results in nondeterministic behaviour • Blacklist approach was abandoned by credit card vendors 20 years ago because it didn’t work properly CRL Problems (ctd) CRLs mirror credit card blacklist problems • Not issued frequently enough to be effective against an attacker • Expensive to distribute • Vulnerable to simple DOS attacks – Attacker can prevent revocation by blocking CRL delivery CRLs add further problems of their own • Can contain retroactive invalidity dates • CRL issued right now can indicate that a cert was invalid last week – Checking that something was valid at time t isn’t sufficient to establish validity – Back-dated CRL can appear at any point in the future • Destroys the entire concept of nonrepudiation .

CRL Problems (ctd) CA cert revocation is more difficult than end-entity revocation • One interop test found that revoking a CA cert would require a “system rebuild” – Replace the current PKI software with updated software • Testing of CA cert revocation was deferred until later CRL Problems (ctd) Revoking self-signed certificates is even hairier • Cert revokes itself • Applications may – Accept the CRL as valid and revoke the certificate – Reject the CRL as invalid since it was signed with a revoked certificate – Crash • Computer version of Epimenides paradoxon “All Cretans are liars” – Crashing is an appropriate response .

all relying parties connect to the CA to fetch the new CRL – Massive peak loads when a CRL expires (DDOS attack) • Issuing CRLs to provide timely revocation exacerbates the problem – 10M clients download a 1MB CRL issued once a minute = ~150GB/s traffic – Even per-minute CRLs aren’t timely enough for high-value transactions with interest calculated by the minute CRL Problems (ctd) • Clients are allowed to cache CRLs for efficiency purposes – CA issues a CRL with a 1-hour expiry time – Urgent revocation arrives.CRL Problems (ctd) CRL Distribution Problems • CRLs have a fixed validity period – Valid from issue date to expiry date • At expiry date. CA issues an (unscheduled) forced CRL before the expiry time – Clients which re-fetch the CRL each time will recognise the cert as expired – Clients which cache CRLs won’t – Users must choose between huge bandwidth consumption/ processing delays or missed revocations .

CRL Problems (ctd) Various ad hoc solutions proposed • Segment CRLs based on urgency of revocation – “Key compromise” issued once a minute – “Affiliation changed” issued once a day – Possible attacks – Substitute one CRL for another – Attacker can place key on low-priority CRL before victim can place it on high-priority CRL • Delta CRLs – Short-term CRLs which modify a main CRL – Discussion on PKI mailing lists indicates that use of delta CRLs will be an interesting experience CRL Problems (ctd) • Stagger CRLs – Over-issue CRLs so that multiple overlapping CRLs exist at one time – Timeliness guarantees vanish – Plays havoc with CRL semantics – Cert may or may not appear on any of several CRLs valid at a given time .

Certificate Revocation (ctd) Many applications require prompt revocation • CA’s (and X.59) • Public key is tied to an existing account • Revocation is handled by removing the key • Matches 1970s model of certificates: “This key is valid at this instant for this account” .f.509) don’t really support this • CA’s are inherently an offline operation Requirements for online checks • Should return a simple boolean value “Certificate is valid/not valid right now” • Can return additional information such as “Not valid because …” • Historical query support is also useful.000 entry CRL to check the status of a single certificate) Bypassing CRLs SET sidesteps CRL problems entirely • End user certificates are “revoked” by cancelling the credit card • Merchant certificates are “revoked” by marking them as invalid at the acquiring bank • Payment gateways have short-term certificates which are quickly replaced Account Authority Digital Signatures (AADS/X9. which can require fetching and parsing a 10. CRLs. “Was valid at the time the signature was generated” • Should be lightweight (c.

Online Status Checking Online Certificate Status Protocol. OCSP OCSP Responder Fetch Validate Cert Check Signature • Inquires of the issuing CA whether a given certificate is still valid – Acts as a simple responder for querying CRL’s – Still requires the use of a CA to check validity Online Status Checking (ctd) OCSP acts as a selective CRL protocol • Standard CRL process: “Send me a CRL for everything you’ve got” • OCSP process: “Send me a pseudo-CRL/OCSP response for only these certs” – Lightweight pseudo-CRL avoids CRL size problems • Reply is created on the spot in response to the request – Ephemeral pseudo-CRL avoids CRL validity period problems .

so any other status = “good” – Much debate among implementors about OCSP semantics Online Status Checking (ctd) Other protocols • Simple Certificate Validation Protocol (SCVP) – Relying party submits a full chain of certificates – Server indicates whether the chain can be verified – Aimed mostly at thin clients • Data Validation and Certification Server Protocols (DVCS) – Provides facilities similar to SCVP disguised as a general third-party data validation mechanism • Integrated CA Services Protocol (ICAP) • Real-time Certificate Status Protocol (RCSP) • Web-based Certificate Access Protocol (WebCAP) • Open CRL Distribution Protocol (OpenCDP) . or “unknown” – “Not revoked” doesn’t necessarily mean “good” – “Unknown” could be anything from “Certificate was never issued” to “It was issued but I can’t find a CRL for it” • Problems are due in some extent to the CRL-based origins of OCSP – CRL can only report a negative result – “Not revoked” doesn’t mean a cert was ever issued – Some OCSP implementations will report “I can’t find a CRL” as “Good” – Some relying party implementations will assume “revoked”  “not good”.Online Status Checking (ctd) • Returned status values are non-orthogonal – Status = “good”. “revoked”.

000 status requests per second • CRL is inherently a batch operation – Once an hour. many more – Protocol debate has been likened to religious sects arguing over differences in dogma • • • • Online Status Checking (ctd) Online protocols place an enormous load on the CA • CA must carefully protect their signing keys … but … • CA must be able to sign x. check for a revocation and produce a signed response – By their very nature. it’s not possible to pre-generate responses.Online Status Checking (ctd) Directory Supported Certificate Status Options (DCS) Data Certification Server (also DCS) Peter’s Active Revocation Protocol (PARP) Delegated Path Validation (DPV) – Offshoot of the SCVP/DVCS debate and an OCSP alternative OCSP-X • Many. since they must be fresh . scan a database table and sign the resulting list • Online status protocols have a high processing overhead – For each query.

Cost of Revocation Checking CAs charge fees to issue a certificate • Most expensive collection of bits in the world Revocation checks are expected to be free • CA can’t tell how often or how many checks will be made • CRLs require – Processor time – Multiple servers (many clients can fetch them) – Network bandwidth (CRLs can get large) • Active disincentive for CAs to provide real revocation checking capabilities Cost of Revocation Checking (ctd) Example: ActiveX • Relatively cheap cert can sign huge numbers of ActiveX controls • Controls are deployed across hundreds of millions of Windows machines • Any kind of useful revocation checking would be astronomically expensive Example: email certificate • Must be made cheap (or free) or users won’t use them • Revocation handling isn’t financially feasible .

worthless • Leave an infrequently-issued CRL at some semi-documented location and hope few people find it Charge for revocation checks • Allows certain guarantees to be associated with the check • Identrus charges for every revocation check (i. web page defacements) • Revocation isn’t necessary since certificates are included in the SSL handshake – Just install a new certificate email key compromise: Who cares? • If necessary. quite literally.f.e.20 each time a certificate was used Rev./Status Checking in the Real World CA key compromise: Everyone finds out • Sun handled revocation of their CA key via posts to mailing lists and newsgroups SSL server key compromise: Noone finds out • Stealing the keys from a typical poorly-secured server isn’t hard (c.Cost of Revocation Checking (ctd) Revocation checking in these cases is. send a copy of your new certificate to everyone in your address book . certificate use) • GSA cost was 40¢…$1.

/Status Checking in the Real World (ctd) In practice./Status Checking in the Real World (ctd) PKI researchers like to tinker with revocation in the same way that petrol-heads tinker with car engines Anyone who can figure out how to make revocation work. revocation checking is turned off in user software • Serves no real purpose. and slows everything down a lot Possible alternative revocation techniques • Self-signed revocation (suicide note) • Certificate of health/warrant of fitness for certificates (antiCRL) Certificate of health provides better proof than CRLs • CRL is a negative statement • Anti-CRL is a positive statement • Proving a negative is much harder than proving a positive Rev. please see me afterwards .Rev.

atomic update propagates across all parties Certificate = invalid . which is down) maintain a standard view of a valid cert B A D E C Certificate = valid B A D E C Certificate is invalidated. all hosts (except E.Revocation as Distributed Trans.Processing View revocation as a distributed transaction processing problem • Allows analysis of requirements and solution using established TP mechanisms • Goal is to distribute certificate status information in a reliable. consistent manner to all parties in the presence of hardware and software failures • All users in a closed community are presented with a guaranteed-consistent view of certificate information – Meets the online status check requirements given earlier Revocation as Distributed TP (ctd) Managing distributed status information Initially.

509 terms this is equivalent to propagating a CRL to all relying parties simultaneously using only a single transaction • Since transaction times are recorded. this system can also resolve historical queries – “Was this cert valid at time t?” – “Was this cert valid at the time it signed this document?” Certificate Chains Collection of certificates from a leaf up to a root or trust anchor • All previous problems are multiplied by the length of the chain CRL CRL Cert RA Cert CRL CA Cert CA Cert • Complexity of revocation checking is proportional to the square of the depth of the issuance hierarchy .Revocation as Distributed TP (ctd) B Crashed server is restarted and also updates its state A D E C Update propagation • In X.

Certificate Chains (ctd) Use OCSP with an access concentrator OCSP Fetch Cert chain Check Validate OCSP Gateway OCSP Signature OCSP • Gateway does all the work • Requests can be forwarded to further gateways • User is billed once at the access concentrator Closing the Circle Fetching a cert and then immediately having to perform a second fetch to determine whether it’s any good is silly • Fetch a known-good cert (no revocation check necessary) • Solves previous revocationchecking problems • Simplify further: Submit hash of certificate on hand – “It’s good. use this one instead” Cert Server Fetch Cert Check Signature . go ahead and use it” – “It’s no good.

etc are historical artifacts/baggage • “Give me the key for John Smith” • This operation is currently performed locally when the key is fetched from a certificate store/Windows registry/flat file • Moving from a local to a remote query allows centralised administration Closing the Circle (ctd) Key-fetch is still an unnecessary step • Validation server performs the check directly • Similar to the 1970’s Davies and Price model Validation – CA provides a dispute resolution Server mechanism via a one-time Check interactive certificate for the transaction Signature • Fits the banking/online settlement transaction model .Closing the Circle (ctd) All we really care about is the key • Issuer/subject DN.

etc) • Shares can be reconstructed under certain conditions (eg death of owner) Defeating this setup requires subverting multiple shareholders Never give the entire key to someone else Never give the key shares to an outside third party . with a solicitor. different location (locked in the company safe. never use a key given to you by someone else (eg generated for you by a third party) Key Backup/Archival (ctd) Use a threshold scheme to handle key backup • Break the key into n shares • Any m of n shares can recover the original • Store each share in a safe.Key Backup/Archival Need to very carefully balance security vs backup requirements • Every extra copy of your key is one more failure point • Communications and signature keys never need to be recovered — generating a new key only takes a minute or so • Long-term data storage keys should be backed up Never give the entire key to someone else • By extension.

bankrupt dot-coms selling user lists after they promised not to – Only asset the CA had left – Bidding quickly shot up to rather high values • Do you want a third-party CA issuing your corporate certs? What is Trust? This term appears constantly in relation to certificates “Alice sees the certificate and trusts Bob” What is trust anyway? Types of trust • Blind trust – Sometimes the only option. don’t even think about it” .f. eg emergencies • Swift trust – Based on a series of hedges to reduce potential loss • Deference-based trust – Disincentive to betray trust – Contract / auditing / “our systems are infallible.Key Destruction Ensure all copies of a private key are destroyed • Is every copy really gone? Public keys may need to survive private keys by quite some time • Signature on 20-year mortgage Long-term key ownership can be a thorny issue • CA goes bankrupt and auctions off keys – c.

What is Trust? (ctd) • Knowledge-based / historical trust – Based on established history / trading relationship • Social trust – Based on emotions rather than rational thought • Identification-based trust – Parties have common goals • Indirect trust – Sometimes. trust can’t be established directly – Establish indirect trust using third parties What is Trust? (ctd) Type of Trust Blind Swift Deference-based Mechanism None necessary None necessary Bilateral trading agreements Contracts/legal agreements Knowledge-based / historical Social trust Identity-based Laws None necessary ― Identity certificates .

trust decays over time • Trust may be deliberately destroyed – “My credit card has been stolen” – Prevents parties from making decisions based on invalid trust data . but we hope for a positive outcome • Psychotic trust – Based on negative evidence – “We’ve done it before and it didn’t work” Much current PKI “trust” is either religious or psychotic What is Trust? (ctd) Trust degradation • Without reinforcement.What is Trust? (ctd) Trust can be grouped into one of three classes • Mechanistic trust – Based on positive evidence – “We’ve done it before and it worked” • Religious trust – Based on faith – No evidence.

Certificate Structure Version (X. usage constraints.509 v3) Serial number Issuer name (DN) Validity (start and end time) Subject Name (DN) Subject public key Extensions (added in v3) Extra identification information. etc Usually either the subject name or issuer and serial number identify the certificate Validity field indicates when certificate renewal fee is due Certificate Structure (ctd) Typical certificate • • • • • • Serial Number = 177545 Issuer Name = Verisign ValidFrom = 12/09/98 ValidTo = 12/09/99 Subject Name = John Doe Public Key = RSA public key . policies.

Certificate Extensions Extensions consist of a type-and-value pair.. or else ignore the extension” .509: Noncritical extension “is an advisory field and does not imply that usage of the key is restricted to the purpose indicated” • PKIX: “CA’s are required to support constraint extensions”. extension must be processed (if recognised) or the certificate rejected • If flag is clear. extension may be ignored Ideally.. but “support” is never defined • S/MIME: Implementations should “correctly handle” certain extensions • MailTrusT: “non-critical extensions are informational only and may be ignored” • Verisign: “all persons shall process the extension. with optional critical flag Critical flag is used to protect CA’s against assumptions made by software which doesn’t implement support for a particular extension • If flag is set. implementations should process and act on all components of all fields of an extension in a manner which is compliant with the semantic intent of the extension Certificate Extensions (ctd) Actual definitions of critical flag usage are extremely vague • X.

509 certificate” nonRepudiation • Binding long-term signature (performed consciously) • Another school of thought holds that nonRepudiation acts as an additional service on top of digitalSignature • Certificate profiles are split roughly 50:50 on this .. you have the right to an attorney. .Certificate Extensions (ctd) Extensions come in two types Usage/informational extensions • Provide extra information on the certificate and its owner Constraint extensions • Constrain the user of the certificate • Act as a Miranda warning (“You have the right to remain silent..”) to anyone using the certificate Certificate Usage Extensions Key Usage • Defines the purpose of the key in the certificate digitalSignature • Short-term authentication signature (performed automatically and frequently) • “This key can sign any kind of document… … except one that happens to look like an X.

crimeFree bit – “This certificate will be used for transactions which are not a perpetration of fraud or other illegal activities” Certificate Usage Extensions (ctd) • Possible definition: “Nonrepudiation is anything which fails to go away when you stop believing in it” – If you can convince someone it’s not worth repudiating a signature. you have nonrepudiation – Have them sign a legal agreement promising not to do it – Convince them that the smart card they used is infallible and it’s not worth going to court over – Threaten to kill their kids • The only definitive statement which can be made upon seeing the NR bit set is “The subscriber asked the issuing CA to set this bit” • Suggestion that CAs set this bit at random just to prevent people from arguing that its presence has a meaning .f.Certificate Usage Extensions (ctd) keyEncipherment • Exchange of encrypted session keys (RSA) keyAgreement • Key agreement (DH) keyCertSign/cRLSign • Signature bits used by CA’s No-one really knows what the nonRepudiation bit signifies • Asking 8 different people will produce 10 different responses • c.

Certificate Usage Extensions (ctd) Extended Key Usage Extended forms of the basic key usage fields • • • • • serverAuthentication clientAuthentication codeSigning emailProtection timeStamping Certificate Usage Extensions (ctd) Two interpretations of what extended key usage values mean when set in a CA certificate • Certificate can be used for the indicated usage – Interpretation used by PKIX. other vendors Netscape cert-type • An older Netscape-specific extension which performed the same role as keyUsage. and basicConstraints . some vendors • Certificate can issue certificates with the given usage – Interpretation used by Netscape. extKeyUsage. Microsoft.

http://www. of which a DN is a little-used subset • otherName – Type-and-value pairs (type=MPEG. but the private key should only be used for a year or two Alternative Names Everything which doesn’t fit in a DN • rfc822Name – email address. ediPartyName – X.wetaburgers. ftp.1 (encoded as CAC51601) • x400Address.Certificate Usage Extensions (ctd) Private Key Usage Period Defines start and end time in which the private key for a certificate is valid • Signatures may be valid for 10-20 years. value=MPEG-of-cat) . but containing stuff you wouldn’t expect to find in the main certificate DN – Actually the alternative name is a form called the GeneralName.com • iPAddress – 202.197.com Certificate Usage Extensions (ctd) • uniformResourceIdentifier – URL.com • dNSName – DNS name for a machine.22.wetaburgers.400 and EDI information • directoryName – Another DN. dave@wetaburgers.

or reliability of information” • Effectively these certificates have null semantics • If CA’s didn’t do this....Certificate Usage Extensions (ctd) Certificate Policies Information on the CA policy under which the certificate is issued • Policy identifier • Policy qualifier(s) • Explicit text (“This certificate isn’t worth the paper it’s not printed on”) Defines/constrains what the CA does. their potential liability would be enormous . Verisign makes no representation that any CA or user to which it has issued a digital ID is in fact the person or organisation it claims to be. Verisign makes no assurances of the accuracy. not what the user does • Passport issuer can’t constrain how a passport is used • Driver’s licence issuer can’t constrain how a driver’s licence is used • SSN issuer can’t even constrain how an SSN is (mis-)used Certificate Usage Extensions (ctd) X.509 delegates most issues of certificate semantics or trust to the CA’s policy • Many policies serve mainly to protect the CA from liability – “Verisign disclaims any warranties. integrity. authenticity..

since keyUsage specifies the same thing in a more precise manner • Much confusion over its use in non-CA certificates – German ISIS profile mandates its use – Italian profile forbids its use .Certificate Usage Extensions (ctd) Policy Mappings • Maps one CA’s policy to another CA • Allows verification of certificates issued under other CA policies – “For verification purposes we consider our CA policy to be equivalent to the policy of CA x” • Mapping of constraints is left hanging Certificate Constraint Extensions Basic Constraints Whether the certificate is a CA certificate or not • Prevents users from acting as CAs and issuing their own certificates • Redundant.

Certificate Constraint Extensions (ctd) Name Constraints Constrain the DN subtree under which a CA can issue certificates • Constraint of C=NZ. DNS names. O=University of Auckland would enable a CA to issue certificates only for the University of Auckland • Main use is to balkanize the namespace so a CA can buy or license the right to issue certificates in a particular area • Constraints can also be applied to email addresses. and URLs Certificate Constraint Extensions (ctd) Policy Constraints Can be used to disable certificate policy mappings • Policy = “For verification purposes we consider our CA policy to be equivalent to the policy of CA x” • Policy constraint = “No it isn’t” .

nameConstraints) to be critical • Uses digitalSignature purely for ephemeral authentication. standards bodies created certificate profiles which nailed down many portions of X. DNS name. keyUsage. certificatePolicies. nonRepudiation specifically for signatures with nonRepudiation • Defines Internet-related altName forms like email address. nonRepudiation for long-term signatures • Defines (in great detail) valid combinations of key usage bits and extensions for various certificate types MISSI US DoD profile • Similar to FPKI but with some DoD-specific requirements (you’ll never run into this one) . interpretation of CA status is left to chance • Uses digitalSignature for general signing.509 PKIX Internet PKI profile • Requires certain extensions (basicConstraints. URL Certificate Profiles (ctd) FPKI (US) Federal PKI profile • Requires certain extensions (basicConstraints.509 is extremely vague and nonspecific in many areas • To make it usable.Certificate Profiles X. keyUsage) to be critical – Doesn’t require basicConstraints in end entity certificates.

encryption. nonRepudiation specifically for signatures with nonRepudiation – nonRepudiation can’t be combined with other flags – Requires three separate keys for digital signature.Certificate Profiles (ctd) ISO 15782 Banking — Certificate Management Part 1: Public Key Certificates • Uses digitalSignature for entity authentication and nonRepudiation strictly for nonrepudiation (leaving digital signatures for data authentication without nonrepudiation hanging) • Can’t have more than one flag set Canada • digitalSignature or nonRepudiation must be present in all signature certs • keyEncipherment or dataEncipherment must be present in confidentiality certs Certificate Profiles (ctd) SEIS Secured Electronic Information in Society • Leaves extension criticality up to certificate policies • Uses digitalSignature for ephemeral authentication and some other signature types. and nonrepudiation • Disallows certain fields (policy and name constraints) .

keyUsage) to be critical • Defines key usage bits (including digitalSignature and nonRepudiation) in terms of which bits may be set for each algorithm type • Defines (in great detail) valid combinations of key usage bits and extensions for various certificate types German Profile Profile to implement the German digital signature law • Requires that private key be held only by the end user .Certificate Profiles (ctd) TeleTrusT/MailTrusT German MailTrusT profile for TeleTrusT (it really is capitalised that way) • Requires keyUsage to be critical in some circumstances • Uses digitalSignature for general signatures. nonRepudiation specifically for signatures with nonRepudiation ISIS German Industrial Signature Interoperability Spec • Only allows some combinations of key usage bits • ISIS extensions should be marked non-critical even if their semantics would make them critical • Requires authorityCertIssuer/SerialNumber instead of authorityKeyIdentifier Certificate Profiles (ctd) Australian Profile Profile for the Australian PKAF • Requires certain extensions (basicConstraints.

It helps if you have some kind of a football team.Certificate Profiles (ctd) SIRCA Profile (US) Securities Industry Association • Requires all extensions to be non-critical • Requires certificates to be issued under the SIA DN subtree Microsoft Profile (de facto profile) • Rejects certificates with critical extensions • Always seems to set nonRepudiation flag when digitalSignature flag set • Ignores keyUsage bit • Treats all certificate policies as the hardcoded Verisign policy Certificate Profiles (ctd) Many. or some nuclear weapons. — Frank Zappa And an X. many more You can't be a real country unless you have a beer and an airline.509 profile. but at the very least you need a beer. — Peter Gutmann Need to • • • • Ensure CA issues certificates conformant to the profile Ensure CA software conforms to the profile Ensure relying party software conforms to the profile Extensively test both to ensure they really do this (rather than just having the vendor claim they do this) .

Setting up a CA No-one makes money running a CA • You make money by selling CA services and products Typical cost to set up a proper CA from scratch: $1M Writing the policy/certificate practice statement (CPS) requires significant effort Getting the top-level certificate (root certificate) installed and trusted by users can be challenging • Root certificate is usually self-signed Bootstrapping a CA Get your root certificate signed by a known CA • Your CA’s certificate is certified by the existing CA • Generally requires becoming a licensee of the existing CA • Your CA is automatically accepted by existing software Get users to install your CA certificate in their applications • • • • Difficult for users to do Specific to applications and OSes Not transparent to users No trust mechanism for the new certificate .

Verisign’s null-semantics certificates .f.uk/Research/Security/ Trust-Register/ • Book containing register of fingerprints of the world’s most important public keys • Implements a top-level CA using paper and ink Install custom software containing the certificate on user PC’s • Even less transparent than manually installing CA certificates • No trust mechanism for the new certificate Business Expectations of a CA Current work follows the “if you build it.Bootstrapping a CA (ctd) Publish your CA certificate(s) by traditional means • Global Trust Register. they will (might) come” model • Industry (particularly governments) make great testbeds for PKI experimentation – They’ll even pay you for it! Survey of US businesses revealed that they require CA’s to be insurable • Must be possible to quantify risk reliably enough to make meaningful warranties • c.cam.ac. http://www.cl.

intimidating warning messages when trying to conduct secure transactions with your site. the government will indemnify you • x expands to “jump through all the hoops defined in this digital signature law” • Type. Ensure each name is unique 2. This will likely impact customer trust and could result in lost business for your site.Business Expectations of a CA (ctd) Two approaches to this problem: 1. size. and number of hoops varies from country to country CA Business Model Free email certs • Noone will pay for them • Clown suit certs SSL certs run as a protection racket • Buy our certs at US$200/kB/year or your customers will be scared away • Actual CA advertising: If you fail to renew your Server ID prior to the expiration date. Protect the CA’s key(s) – Interpreting the certificate is left to the relying party 2. CA consulting services . Practical solution: CA has only two warranted responsibilities 1. operating your Web site will become far riskier than normal […] your Web site visitors will encounter multiple. Legal solution: If you do x.

. authenticity. or reliability of information” Finding a Workable Business Model (ctd) A PKI is not just another IT project • Requires a combined organisational. multidisciplinary team • Complexity is enormous – Initial PKI efforts vastly underestimated the amount of work involved – Current work is concentrating on small-scale pilots to avoid this issue To be accepted. makes no representation that any CA or user to which it has issued a digital ID is in fact the person or organisation it claims to be. procedural. a PKI must provide perceived value • Failure to do so is what killed SET • Noone has really figured out a PKI business model yet . makes no assurances of the accuracy... and legal approach • Staffing requires a skilled. integrity..Finding a Workable Business Model PKI requires of the user • Certificate management software to be installed and configured • Payment for each certificate • Significant overhead in managing keys and certificates PKI provides to the user • “…disclaims any warranties.

accurate information – Protect private key – Notify CA on private key compromise CA Policies (ctd) • List of applications for which issued certificates may be used/may not be used • CA liability – Warranties and disclaimers • Financial responsibility – Indemnification of the CA by certificate users • Certificate publication details – Access mechanism – Frequency of updates – Archiving • Compliance auditing – Frequency and type of audit – Scope of audit .CA Policies Serves two functions • Provides a CA-specific mini-profile of X.509 • Defines the CA terms and conditions/indemnifies the CA CA policy may define • Obligations of the CA – Checking certificate user validity – Publishing certificates/revocations • Obligations of the user – Provide valid.

who can request a revocation. how revocation notices are distributed • Key changeover – How keys are rolled over when existing ones expire • Disaster recovery .CA Policies (ctd) • Security auditing – Which events are logged – Period for which logs are kept – How logs are protected • Confidentiality policy – What is/isn’t considered confidential – Who has access – What will be disclosed to law enforcement/courts CA Policies (ctd) • Certificate issuing – Type of identification/authentication required for issuance – Type of name(s) issued – Resolution of name disputes – Handling of revocation requests – Circumstances under which a certificate is revoked. type of identification/authentication required for revocation.

network security controls – CA key protection – Generation. access control. data backup – Personnel security – Background checks. key sizes. protection (hardware or software. training – Computer security – OS type used. fire/flood protection. key backup/archival. access control mechanisms. access/control over the key handling software/hardware) • Certificate profiles – Profile amendment procedures – Publication CA’s and Scaling The standard certification model involves direct user interaction with a CA This doesn’t scale well • CA has to verify details for each user • Processing many users come from a similar background (eg a single organisation) results in unnecessary repeated work .CA Policies (ctd) • CA security – Physical security – Site location. which protection standards are employed.

RA’s Registration authorities offload user processing and checking from the CA RA acts as a trusted intermediary • RA has a trusted relationship with CA • RA has access to user details Timestamping Certifies that a document existed at a certain time Used for added security on existing signatures • Timestamped countersignature proves that the original signature was valid at a given time • Even if the original signatures key is later compromised. the timestamp can be used to verify that the signature was created before the compromise Requires a data format which can handle multiple signatures • Only PGP keys and S/MIME signed data provide this capability .

509 Most of the required infrastructure doesn’t exist • Users use an undefined certification request protocol to obtain a certificate which is published in an unclear location in a nonexistent directory with no real means to revoke it • Various workarounds are used to hide the problems – Details of certificate requests are kludged together via web pages – Complete certificate chains are included in messages wherever they’re needed – Revocation is either handled in an ad hoc manner or ignored entirely Standards groups are working on protocols to fix this • Progress is extremely slow Problems with X. buy goods in a store. even names – An owner will typically have multiple certificates.509 (ctd) Certificates are based on owner identities.Problems with X. email addresses. all with the same ID • Owner identity is rarely of security interest (authorisation/ capabilities are what count) – When you check into a hotel. you’re asked for a payment instrument. not a passport • Revoking a key requires revoking the identity of the owner • Renewal/replacement of identity certificates is nontrivial . not keys • Owner identities don’t work very well as certificate ID’s – Real people change affiliations.

get a suntan.Problems with X. switch to contact lenses.509 (ctd) Authentication and confidentiality certificates are treated the same way for certification purposes • X.509 (ctd) Aggregation of attributes shortens the overall certificate lifetime • Steve’s Rule of Revocation: Frequency of certificate change is proportional to the square of the number of attributes • Inflexibility of certificate conflicts with real-world IDs – Can get a haircut. without invalidating your passport – Changing a single bit in a certificate requires getting a new one – Steve’s certificate is for an organisation which no longer exists . shave off a moustache. go on a diet.509v1 and v2 couldn’t even distinguish between the two Users should have certified authentication keys and use these to certify their own confidentiality keys • No real need to have a CA to certify confidentiality keys • New confidentiality keys can be created at any time • Doesn’t require the cooperation of a CA to replace keys Problems with X.

Problems with X.509 (ctd) Certificates rapidly become a dossier as more attributes are added SEQUENCE { OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) [0] { SEQUENCE { INTEGER 1 SET { SEQUENCE { OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) NULL } } SEQUENCE { OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) } [0] { SEQUENCE { SEQUENCE { [0] { INTEGER 2 } INTEGER 145 SEQUENCE { OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1 1 4) NULL } SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER countryName (2 5 4 6) PrintableString 'CH' } }SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Swisskey AG' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Public CA Services' } } SET { SEQUENCE { OBJECT IDENTIFIER localityName (2 5 4 7) PrintableString 'Zuerich' } } SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) PrintableString 'Swisskey ID CA 1024' } } } continues Problems with X.ch' } } } SEQUENCE { SEQUENCE { OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) NULL } BIT STRING 0 unused bits 30 81 89 02 81 81 00 EE 7B BA 00 A0 1A C2 05 8B 8F 52 26 E9 01 C4 A3 7A C9 6E C5 4C 2B FD 3A 2A 44 48 72 29 7E E3 57 03 2A C9 F3 BB 1D C2 12 2D E7 7E 8D B3 3C 58 AD D6 8A 29 4D D1 9F 0F 1E 45 F3 1E 67 39 9D 83 0B 1A 0D 1F 82 35 B0 D7 2A 6E 35 6B 76 C2 05 9B 67 E4 3F 8B 6A 8F A6 04 85 F7 56 EB 51 D9 69 D6 C9 23 AF 5E 0A AE D3 90 7F 60 16 81 CF 1F 20 B6 A5 A5 5E F0 9F 6D B0 40 F9 8D [ Another 12 bytes skipped ] } continues .509 (ctd) SEQUENCE { UTCTime '980929093816Z' UTCTime '000929093800Z' } SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Swisskey AG' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString '008510000050200000128' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Product Management' } } SET { SEQUENCE { OBJECT IDENTIFIER postalCode (2 5 4 17) PrintableString '8008' } } SET { SEQUENCE { OBJECT IDENTIFIER localityName (2 5 4 7) PrintableString 'Zuerich' } } SET { SEQUENCE { OBJECT IDENTIFIER countryName (2 5 4 6) PrintableString 'CH' } } SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) PrintableString 'Juerg Spoerndli' } } SET { SEQUENCE { OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1) IA5String 'jspoerndli@swisskey.

encapsulates { BIT STRING 5 unused bits '101'B } } SEQUENCE { OBJECT IDENTIFIER privateKeyUsagePeriod (2 5 29 16) OCTET STRING.Problems with X.509 (ctd) [3] { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER netscape-cert-type (2 16 840 1 113730 1 1) OCTET STRING. encapsulates { SEQUENCE { [0] '19980929093816Z' [1] '20000929093800Z' } } } } } } SEQUENCE { OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1 1 4) NULL } BIT STRING 0 unused bits 2A 2A 40 C4 03 48 0B B9 7D 7F B6 85 FD CF A8 D7 CF 96 D8 55 5D C0 87 4D BE E6 C1 0F 7A 0B 0F 17 DF 7A 10 49 81 EB A1 6B 8C 16 93 FB 38 37 79 A0 B6 1F B3 EA F0 AA D5 CA 0A 52 DA D3 19 3A 55 B6 F6 7F 77 4E 30 15 D4 5C 8C 73 44 62 FF 15 9C 44 C3 38 F0 D1 58 85 D0 C6 88 55 7C FF D0 67 14 4C DE D2 7F F8 00 A8 BC 6E A7 35 BD 51 DD CB 7D F2 C8 E7 34 61 00 C2 25 51 F0 ED 0B B0 38 93 FC 30 } SEQUENCE { SEQUENCE { [0] { INTEGER 2 } INTEGER 5 SEQUENCE { OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1 1 4) NULL } continues Problems with X.509 (ctd) SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER countryName (2 5 4 6) PrintableString 'CH' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Swisskey AG' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Public CA Services' } } SET { SEQUENCE { OBJECT IDENTIFIER localityName (2 5 4 7) PrintableString 'Zuerich' } } SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) PrintableString 'Swisskey Root CA' } } } SEQUENCE { UTCTime '980706134849Z' UTCTime '051231235900Z' } SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER countryName (2 5 4 6) PrintableString 'CH' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Swisskey AG' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Public CA Services' } } SET { SEQUENCE { OBJECT IDENTIFIER localityName (2 5 4 7) PrintableString 'Zuerich' } } SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) PrintableString 'Swisskey ID CA 1024' } } } SEQUENCE { SEQUENCE { OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) NULL } continues . encapsulates { BIT STRING 5 unused bits '101'B } } SEQUENCE { OBJECT IDENTIFIER netscape-comment (2 16 840 1 113730 1 13) OCTET STRING 16 81 C6 54 68 69 73 20 63 65 72 74 69 66 69 63 61 74 65 20 68 61 73 20 62 65 65 6E 20 69 73 73 75 65 64 20 62 79 20 53 77 69 73 73 6B 65 79 20 41 47 20 67 6F 76 65 72 6E 65 64 20 62 79 20 69 74 73 20 43 65 72 74 69 66 69 63 61 74 65 20 50 72 61 63 74 69 63 65 20 53 74 61 74 65 6D 65 6E 74 20 28 43 50 53 29 2E 20 43 50 53 20 61 6E 64 20 66 75 72 74 68 65 72 20 69 6E 66 6F 72 6D 61 [ Another 73 bytes skipped ] } SEQUENCE { OBJECT IDENTIFIER keyUsage (2 5 29 15) OCTET STRING.

509 (ctd) SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Public CA Services' } } SET { SEQUENCE { OBJECT IDENTIFIER localityName (2 5 4 7) PrintableString 'Zuerich' } } SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) PrintableString 'Swisskey Root CA' } } } SEQUENCE { UTCTime '980706120207Z' UTCTime '051231235900Z' } SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER countryName (2 5 4 6) PrintableString 'CH' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Swisskey AG' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Public CA Services' } } SET { SEQUENCE { OBJECT IDENTIFIER localityName (2 5 4 7) PrintableString 'Zuerich' } } SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) PrintableString 'Swisskey Root CA' } } } SEQUENCE { SEQUENCE { OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) NULL } continues . encapsulates { SEQUENCE { BOOLEAN TRUE INTEGER 0 } } } SEQUENCE { OBJECT IDENTIFIER keyUsage (2 5 29 15) BOOLEAN TRUE OCTET STRING. encapsulates { BIT STRING 1 unused bits '1100000'B } } } } } SEQUENCE { OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1 1 4) NULL } BIT STRING 0 unused bits 0E 0F 67 22 AA D2 8A 7B BF 3D 47 AB 1F 5E 8C F3 2C 32 3E AB D3 48 60 A1 BA 49 FD 81 28 6A 26 69 83 97 29 1F E8 80 14 96 30 2B C3 18 97 3B 6C F3 F0 A2 D6 E0 30 EF F6 2C 38 1F C0 37 7E 9E 45 FD 62 38 67 07 27 BE 81 07 E9 12 60 E8 BE 6B ED 14 8E 61 17 52 99 C2 FE 33 B7 21 CA 5E FE 6D B4 1E B9 8C 54 36 42 55 1E 73 D9 81 DE 5D 25 AD 72 39 15 AF 68 E9 44 45 55 7F 2E 2E F9 6F EF 44 B0 E0 } SEQUENCE { SEQUENCE { [0] { INTEGER 2 } INTEGER 1 SEQUENCE { OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1 1 4) NULL } SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER countryName (2 5 4 6) PrintableString 'CH' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Swisskey AG' } } continues Problems with X.509 (ctd) BIT STRING 0 unused bits 30 81 89 02 81 81 00 AB E9 1F E9 AD FF 53 9F 71 70 35 6D F8 F8 4C 76 B4 F7 43 E8 19 80 DD A9 0A D6 4E 60 C2 FD 48 7B 43 F6 6E BE 53 D0 0E 62 F0 35 27 6F 2E 55 22 F2 82 40 2E 21 5B 5D 7E 18 16 CA 87 31 2E 12 71 4C 5F 92 8A AB 36 61 9C 91 38 BC BD 95 88 BF 7E 0C 4A D7 A0 12 F9 FA FF 0F 84 F8 57 6E DE AE B4 03 FC 77 CF 7C E5 B3 33 79 61 31 4E CE 70 03 E7 73 D8 E8 1B D3 EB 15 FF 69 B3 [ Another 12 bytes skipped ] } [3] { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER basicConstraints (2 5 29 19) BOOLEAN TRUE OCTET STRING.Problems with X.

encapsulates { SEQUENCE { BOOLEAN TRUE INTEGER 3 } } } SEQUENCE { OBJECT IDENTIFIER keyUsage (2 5 29 15) BOOLEAN TRUE OCTET STRING. encapsulates { BIT STRING 1 unused bits '1100000'B } } } } } SEQUENCE { OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1 1 4) NULL } BIT STRING 0 unused bits 72 A7 93 A3 CD D7 3A DB 79 50 DB 98 03 52 B0 CD AF 0C D2 A6 89 38 52 6C 5C E9 7C B3 37 3C 9E 94 C4 74 57 D4 BB 78 05 5B B6 B9 31 04 FC 60 33 51 5F CF 2C 44 55 85 EC 1F 0B CB 89 E7 F0 93 D4 CD 85 D3 FF B6 B5 99 D3 7C 35 06 11 7B 0E 9F E6 BE 99 B3 49 D0 5A 85 FA 7C BA 54 9B B9 AF F7 4B E3 FF DC 83 4A 04 F8 F9 A5 1D EC 37 AE C6 23 4C 9D B2 01 1F D4 26 EA E4 4A 7E BE BE 1E 11 1E 27 D1 } } SET { SEQUENCE { INTEGER 1 SEQUENCE { SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER countryName (2 5 4 6) PrintableString 'CH' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Swisskey AG' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Public CA Services' } } continues Problems with X.509 (ctd) SET { SEQUENCE { OBJECT IDENTIFIER localityName (2 5 4 7) PrintableString 'Zuerich' } } SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) PrintableString 'Swisskey ID CA 1024' } } } INTEGER 145 } SEQUENCE { OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) NULL } [0] { SEQUENCE { OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3) SET { OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) } } SEQUENCE { OBJECT IDENTIFIER signingTime (1 2 840 113549 1 9 5) SET { UTCTime '981113072133Z' } } SEQUENCE { OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4) SET { OCTET STRING 2F 7E 95 9F 34 AC 85 B8 1C 53 9E 5C F8 60 BE 3A AA D0 30 B5 } } SEQUENCE { OBJECT IDENTIFIER sMIMECapabilities (1 2 840 113549 1 9 15) SET { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7) } SEQUENCE { OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2) INTEGER 128 } SEQUENCE { OBJECT IDENTIFIER desCBC (1 3 14 3 2 7) } SEQUENCE { OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2) INTEGER 64 } SEQUENCE { OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2) INTEGER 40 } } } } } continues .509 (ctd) BIT STRING 0 unused bits 30 81 89 02 81 81 00 AC AB 60 E0 C5 69 FD 07 4E 97 9B AF 4A 1C 30 D7 68 26 D1 2C 3D 44 F0 D6 AB 16 34 6F 00 D8 7F D6 3F B9 35 D6 83 28 77 A3 3E 24 5D A4 D1 C2 FA 04 B3 DB 4D 38 91 23 70 6C 2B 2D 48 69 D5 15 6F 4A 9F 91 BC E4 83 2F 35 A2 29 DB 55 66 F8 90 C6 0E 0C 32 75 95 24 E0 8D B7 8E AB 13 70 61 1E 01 91 7D 9D 44 37 42 41 C9 C2 01 DD 26 D8 B9 2C 29 57 A1 54 17 1E AC 1A DE 8C 6C [ Another 12 bytes skipped ] } [3] { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER basicConstraints (2 5 29 19) BOOLEAN TRUE OCTET STRING.Problems with X.

509 (ctd) Hierarchical certification model doesn’t fit typical business practices • Businesses generally rely on bilateral trading arrangements or existing trust relationships • Third-party certification is an unnecessary inconvenience when an existing relationship is present X. well-established one • In the real world.509 PKI model entails building a parallel trust infrastructure alongside the existing. trust and revocation is handled by closing the account.509 (ctd) SEQUENCE { OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) NULL } OCTET STRING 9F EC C4 B4 B2 5A FE 87 EA 28 22 C2 6A 1F E3 2F 16 8D 01 EA 2F 35 0E 13 D1 3E BE 1D 92 48 EF F0 8E BB BC 98 3B 11 44 88 A8 20 AE AB 65 2D 98 E1 3E 62 E1 47 5F FE 18 39 AF 97 29 7E D1 68 03 F1 03 78 44 DB A1 BB 9F 3B C9 89 D5 0D 00 B3 0B FA 98 F8 2E 58 4C E4 4F 73 02 D6 17 41 84 B6 50 A2 94 F8 E2 6F C3 78 AF 4D 71 CF E7 FF 25 97 B9 00 CC A5 BE A8 8C 3D 52 43 C9 BB 41 A9 87 5F 85 6F } } } } } All this from a standard S/MIME signature! Problems with X.Problems with X. certificate status checks. and other paraphernalia . CRLs. not with PKIs.

509 (ctd) – Do they owe a duty of care. so they can’t go after the keyholder) • On the whiteboard: “Alice does something magical/mathematical with Bob’s key. including obligations for signatures made with their private key In an open system • Parties have no previously established network of contracts covering private key use on which they can rely – On what basis do you sue someone when they repudiate a signature? – Have they published a legally binding promise to the world to stand behind that signature? Problems with X. Identrus) • Members sign up to the rules of the club • Only members who will play by the rules and can carry the risk are admitted • Members are contractually obliged to follow the rules.Problems with X. and the judge says ‘Obviously Bob is guilty’” • In practice: Would you like to be the test case? .509 (ctd) In a closed system (SWIFT. actionable in the case of negligence? • Possible ways to proceed – Claim a duty of care where negligence resulted in financial loss (generally negligence claims for pure financial loss won’t support this) – Claim that publishing the key was a negligent misstatement (unlikely that this will work) – Go after the CA (CA won’t suffer any loss if the keyholder is negligent.

by definition.Problems with X.509 (ctd) Certificates don’t model standard authority delegation practices • Manager can delegate authority/responsibility to an employee – “You’re in charge of purchasing” • CA can issue a certificate to an employee. but can’t delegate the responsibility which comes with it Residential certificates are even more problematic • Noone knows who has the authority to sign these things Problems with Implementations Relying parties must. be able to rely on the handling of certificates Currently difficult to do because of • • • • Implementation bugs Different interpretations of standards by implementors Implementation of different parts of standards Implementation of different standards .

com – Can often get away with President George W.Problems with Implementations (ctd) Examples of common problems • rfc822Name has ambiguous definition/implementation (Assorted standards/implementations) – Should be used as luser@aol. etc – Can make identical-appearing strings compare as different strings – Can also evade name constraints by using altNames Problems with Implementations (ctd) • Software crashes when it encounters a Unicode or UTF-8 string (Netscape) – Some other software uses Unicode for any non-ASCII characters. floating diacritics.com> • Name constraints can be avoided through creative name encoding (Problem in standards) – Multiple encodings for the same character.Bush <luser@aol. zero-width spaces. guaranteeing a crash – At least one digital signature law requires the (unnecessary) use of Unicode for a mandatory certificate field – Standards committee must have had MS stockholders on it • Software produces negative numeric values because the implementors forgot about the sign bit (Microsoft and a few others) – Everyone changed their code to be bug-compatible with MS • Software hardcodes the certificate policy so that any policy is treated as if it were the Verisign one (Microsoft) .

the software will grab the first one it finds and use it for both purposes – CryptoAPI seems to mostly ignore usage constraints on keys – AT_KEYXECHANGE keys (with corresponding certificates) can be used for signing and signature verification without any trouble . unknown extensions marked critical are accepted (Microsoft) – Due to a reversed flag in the MS certificate handling software – Other vendors and CAs broke their certificates in order to be bug-compatible with MS – Later certs were broken in order to be bug-compatible with the earlier ones – Spot check: If you have a cert from a public CA. check whether the important extensions are marked critical or not Problems with Implementations (ctd) • Software ignores the key usage flags and uses the first cert it finds for the purpose it needs (Microsoft) – If users have separate encryption and signing certs.Problems with Implementations (ctd) • Known extensions marked critical are rejected.

Problems with Implementations (ctd) • Cert chaining by name is ignored (Microsoft) – Certificate issued by “Verisign Class 1 Public Primary Certification Authority” could actually be issued by “Honest Joe’s Used Cars and Certificates” – “No standard or clause in a standard has a divine right of existence” – MS PKI architect – Given the complete chaos in DNs. this isn’t quite the blatantly wrong decision which it seems Problems with Implementations (ctd) • Obviously bogus certificates are accepted as valid (Microsoft) -----BEGIN CERTIFICATE----MIIQojCCCIoCAQAwDQYJKoZIhvcNAQEEBQAwGDEWMBQGA1UEAxMNS29tcGxleCBM YWJzLjAeFw01MTAxMDEwMDAwMDBaFw01MDEyMzEyMzU5NTlaMBgxFjAUBgNVBAMT DUtvbXBsZXggTGFicy4wggggMA0GCSqGSIb3DQEBAQUAA4IIDQAwgggIAoIIAQCA A+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +//////////////////////////////////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///++++HELLO+THERE++++////////////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///And/welcome/to/the/base64/coded/x509/pem/certificate/of////+ +//////////////////////////////////////////////////////////////+ +///KOMPLEX/MEDIA/LABS/////////////////////////////////////////+ +///www/dot/komplex/dot/org////////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///created/by/Markku+Juhani/Saarinen//////////////////////////+ +///22/June/2000///dw3z/at/komplex/dot/org/////////////////////+ +//////////////////////////////////////////////////////////////+ +///You/are/currently/reading/the/public/RSA/modulus///////////+ +///of/our/root/certification/authority/certificate////////////+ +//////////////////////////////////////////////////////////////+ +///Which/happens/to/be/16386/bits/long////////////////////////+ +//////////////////////////////////////////////////////////////+ +///And/fully/working/and/shit/////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///And/totally/insecure///////////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///You/can/save/this/text/to/a/file/called/foo/dot/crt////////+ +///Then/click/on/it/with/your/explorer/and/you/can/see////////+ +///that/your/system/doesn+t/quite/trust/the/komplex/root//////+ +///CA/yet+////////////////////////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///But/that+s/all/right///////////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///Just/install/it////////////////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///And/you+re/happily/part/of/our/16386/bit/public/key////////+ +///infrastructure/////////////////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///One/more/thing/////////////////////////////////////////////+ +//////////////////////////////////////////////////////////////+ +///Don+t/try/read/this/with/other/PKI/or/S/MIME/software//////+ .

but accepts it anyway – Exponent is 1 (bogus key) but cert is accepted as valid Problems with Implementations (ctd) • End entity certificates are encoded without the basicConstraints extension to indicate that the certificate is a non-CA cert (PKIX) – Some apps treat these certificates as CA certificates for X. then time out and continue anyway – Some newer versions forget to perform certificate validity checks (eg expiry times.509v1 compatibility – May be useful as a cryptographically strong RNG – Issue 128 certificates without basicConstraints – User other app’s CA/non-CA interpretation as one bit of a key – Produces close to 128 bits of pure entropy • CRL checking is broken (Microsoft) – Older versions of MSIE would grope around blindly for a minute or so. CA certs) if CRL checking enabled .Problems with Implementations (ctd) – Validity period is actually December 1951 to December 2050 – At one point MS software was issuing certificates in the 17th century – This was deliberate – Software reports it as December 1950 to December 1950.

we need to insert one more level of CA into the path due to a company reorg/merger – Ordering/non-ordering of DN elements – Allow only one attribute type (eg OU) per DN – Assume CN is always encoded last Problems with Implementations (ctd) • The lunatic fringe: Certs from vendors like Deutsche Telekom/Telesec are so broken they would create a matter/antimatter reaction if placed in the same room as an X.509 spec – “Interoperability considerations merely create uncertainty and don't serve any useful purpose. The market for digital signatures is at hand and it's possible to sell products without any interoperability” – Telesec project leader (translated) – “People will buy anything as long as you tell them it’s X.509” (shorter translation) . but traditionally filled with a binary hash value – Number/size of DN elements – Size of encoded DN – Certificate path/chain length – Path length constraints – Oops.Problems with Implementations (ctd) • Applications enforce arbitrary limits on data elements (GCHQ/CESG interop testing) – Size of serial number – Supposedly an integer.

money and resources will be required • “PKI will get rid of passwords” – Current implementations = password + private key – Passwords with a vengeance • Certificate revocation doesn’t really work – Locating the certificate in the first place works even less • • • • .Problems with an X.509-style PKI PKI will solve all your problems • • • • PKI will make your network secure PKI will allow single sign-on PKI solves privacy problems PKI will allow <insert requirement which customer will pay money for> • PKI makes the sun shine and the grass grow and the birds sing Problems with an X.509-style PKI (ctd) Reality vs hype Very little interoperability/compatibility Lack of expertise in deploying/using a PKI No manageability Huge up-front infrastructure requirements – Few organisations realise just how much time.

British Airways.com aka http://www.ual.500 airline ticket from United Airlines • Site is http://www.com • Browser shows the SSL padlock – Certificate is verified (transparent to the user) – It’s safe to submit the $1.net – American Airlines don’t seem to use any security at all – Quantas don’t even have a web site .500 payment request How Effective are Certificates Really? (ctd) But • Actual site it’s being sent to is itn. California – Who are these people? – Site contains links to the Amex web site – Anyone can add links to Amex site to their home page though • Just for comparison – Singapore Airlines.net • Company is located in Palo Alto. and Lufthansa have appropriate certificates – Air New Zealand also uses itn.How Effective are Certificates Really? Sample high-value transaction: Purchase $1.united.

How Effective are Certificates Really? (ctd) This is exactly the type of situation which SSL certificates are intended to prevent • Browsers don’t even warn about this problem because so many sites would break – Outsourcing of merchant services results in many sites handling SSL transactions via a completely unrelated site • Effectively reduces the security to unauthenticated DiffieHellman Most current certificate usage is best understood by replacing all occurrences of the term “trusts” with “relies upon” or “depends upon”. even on a permessage basis . not identity-based • Keys can have one or more free-form names attached • Key and name(s) are bound through (independent) signatures Certification model can be hierarchical or based on existing trust relationships • Parties with existing relationships can use self-signed certificates – Self-signed end entity certificates are a logical paradox in X.509v3 Authentication keys are used to certify confidentiality keys • Confidentiality keys can be changed at any time. generally with an implied “has no choice but to …” at the start PGP Certificates Certificates are key-based.

but require a parallel infrastructure to make use of the result SPKI certificates bind a key to an authorisation or capability .Alternative Trust Hierarchies PGP web of trust Bob knows B and D who know A and C who know Alice  Bob knows the key came from Alice Web of trust more closely reflects real-life trust models SPKI Simple Public Key Infrastructure Identity certificates bind a key to a name.

509 dossier certificates) If names are used. they only have to be locally unique • Global uniqueness is guaranteed by the use of the key as an identifier • Certificates may be anonymous (eg for balloting) Authorisation may require m of n consensus among signers (eg any 2 of 3 company directors may sign) SPKI Certificate Uses Typical SPKI uses • • • • • • • • • • Signing/purchasing authority Letter of introduction Security clearance Software licensing Voter registration Drug prescription Phone/fare card Baggage claim check Reputation certificate (eg Better Business Bureau rating) Access control (eg grant of administrator privileges under certain conditions) .SPKI (ctd) Certificates may be distributed by direct communications or via a directory Each certificate contains the minimum information for the job (cf X.

. ( not-before “1998-03-01_12:42:17” ) ( not-after “2012-01-01_00:00:00” ) )  X.. Authority..org ) )  Keyholder is allowed FTP access to an entire site ( ftp ( host ftp.500 DN ( name ( hash sha1 |TLCgPLFlGTzyUbcaYLW8kGTEnUk=| ) fred )  Globally unique name with key ID and locally unique name ( ftp ( host ftp. SPKI certificates are represented as 5-tuples <Issuer.warez. Delegation.509 certificate Internally..Certificate Structure SPKI certificates use collections of assertions expressed as LISP-like S-expressions of the form ( type value(s) ) ( name fred )  Owner name = fred ( name CA_root CA1 CA2 . CAn leaf_cert )  X.warez. Validity> • Delegation = Subject has permission to delegate authority • Authority = Authority granted to certificate subject • Validity = Validity period and/or online validation test information .org ) ( dir /pub/warez ) )  Keyholder is allowed FTP access to only one directory on the site Certificate Structure (ctd) ( cert ( issuer ( hash sha1 |TLCgPLFlGTzyUbcaYLW8kGTEnUk=| )) ( subject ( hash sha1 |Ve1L/7MqiJcj+LSa/l10fl3tuTQ=l| ) ) . Subject.

D1. Signed: A • Service provider. D. Signed: Service Provider • B may access resource X. x. A2. V> • All others are discarded Trust Evaluation (ctd) Example authorisation chain • A may access resource X. D2. intersection( V1. intersection( A1. A1. S2. V1> + <I2. or external intervention • Trust management decisions can be justified/explained/verified – “How was this decision reached?” – “What happens if I change this bit?” X. please allow me to access X. Signed: B Verification • Service provider checks signatures from B  A  own key • Authorisation loop requires no CA. V2 ) if S1 = I2 and D1 = true Eventually some chains of authorisation statements will reduce to <Trusted Issuer. D2. S2.Trust Evaluation 5-tuples can be automatically processed using a generalpurpose tuple reduction mechanism <I1. trusted third party. V2>  <I1. A.509 has nothing even remotely like this . S1. A2 ).

PKI Design Guidelines Identity • Use a locally meaningful identifier – User name – email address – Account number • Don't try and do anything meaningful with DNs PKI Design Guidelines (ctd) Revocation • If possible. use a mechanism which provides freshness guarantees • If that isn't possible. use an online status query mechanism – Valid/not valid responder – OCSP • If the revocation is of no value. use CRLs .59 – ssh – SSL • If that isn't possible. design your PKI so that revocation isn't required – SET – AADS/X9.

509 binds a key to an (often irrelevant) identity which must then somehow be mapped to an authorisation • PGP – Designed to secure email – Laissez-faire key management tied to email address solves "Which directory" and "Which John Doe" problems PKI Design Guidelines (ctd) In many situations no PKI of any kind is needed • Example: Authority-to-individual communications (eg tax filing) – Obvious solution: S/MIME or PGP – Practical solution: SSL web server with access control – Revocation = disable user access – Instantaneous – Consistently applied – Administered by the organisation involved. not some third party .PKI Design Guidelines (ctd) Application-specific PKIs • PKIs designed to solve a particular problem are easier to work with than a one-size-(mis)fits all approach • SPKI – Binds a key to an authorisation – X.

use it Be careful about holding your business processes hostage to your PKI (or lack thereof) .59 – Ties keys to existing accounts – Handled via standard business mechanisms – Revocation = remove key/close account • Example: Business transactions – Ask Citibank about certificate validity vs – ask Citibank to authorise the transaction directly → Use an online authorisation – (US) Business Records Exception allows standard business records to be treated as evidence in court – Following standard legal precedent is easier than becoming a test case for PKI PKI Design Guidelines (ctd) There's nothing which says you have to use X.PKI Design Guidelines (ctd) • Example: AADS/X9.509 as anything more than a complex bit-bagging scheme • If you have a cert management scheme which works.

Digital Signature Legislation A signature establishes validity and authentication of a document to allow the reader to act on it as a statement of the signers intent Signatures represent a physical manifestation of consent A digital signature must provide a similar degree of security Digital Signature Legislation (ctd) Typical signature functions are • • • • • • • • Identification Prove involvement in the act of signing Associate the signer with a document Provide proof of the signers involvement with the content of the signed document Provide endorsement of authorship Provide endorsement of the contents of a document authored by someone else Prove a person was at a given place at a given time Meet a statutory requirement that a document be signed to make it valid .

which one do they use on which occasion? .Real-world vs Electronic Signatures Real-world pen-and-ink signatures use • A standard pen • A standard hand/wrist • Standard handwriting But… • The user is aware of the importance of their action Proposed digital signatures use • Different keys • Different certificate policies • Different CAs Do you use a different hand/wrist to write a letter and sign it? Real-world vs Electronic Signatures (ctd) The difference between plain handwriting and a signature is informed consent • Digital signatures artificially split key functionality because the standards are mostly written by technologists who can’t define law or social policy • When do you use a digital-signature vs general-signature key? – Signing a challenge-response authentication token? – Signing a letter of introduction? – Signing an inter-office memo? – Signing a purchase order? – Signing a receipt • If a user has a handful of signing keys.

Z for credit cards/ATM cards ..Real-world vs Electronic Signatures (ctd) The credit-card approach • You may use your VISA with approved VISA merchants • You may use the XYZ signature key with approved XYZ business partners – Identrus adopt this approach Other approaches are still awaiting legal test cases… General Requirements for Digital Signatures The signing key must be controlled entirely by the signer for non-repudiation to function The act of signing must be conscious • The “Grandma clicks the wrong button and loses her house” problem • “You are about to enter into a legally binding agreement which stipulates that .” Non-repudiation can best be achieved through laws guaranteeing repudiation • That’s “guaranteeing repudiation”. Reg..f.E/Reg. not “guaranteeing nonrepudiation” • c.

. etc etc.. I agree to . Duly authorised digital signatures may be used to meet statutory requirements for written signatures Liability of CA’s is limited. signers and relying parties assume the risk Signature carries evidentiary weight of notarised document • If your key is compromised. you’re in serious trouble • If you hand over your key to a third party. under the terms . CRL’s.. you’re in serious trouble .” • Written German HBCI (Home Banking Computer Interface) agreement (Ini-Brief) has – Key owner identification information – Date/time – Key and hash of key – “I certify that this key is used for my electronic signature” Cross-jurisdictional signatures are a problem Utah Digital Signature Act First digital signature act. passed in 1995 The Law of X..General Requirements for Digital Sigs (ctd) May require a traditional written document to back up the use of electronic signatures • “With the key identified by .509 • Requires public-key encryption based signatures... licensed CA’s.

. on the sole ground that the contract is evidenced by an electronic record or that it has been signed by an electronic signature” The Massachusetts law doesn’t legislate forms of signatures or the use of CA’s. allows any agreed-upon mark to be used as a digital signature • Western culture has no real analog for this • Asia has chop-marks. a general-purpose mark used to authenticate and authorise One-sentence digital signature law: “You can’t refuse a signature just because it’s digital” • Many later laws followed this model Massachusetts Electronic Records and Signatures Bill “A signature may not be denied legal effect. or enforceability because it is in the form of an electronic signature. validity.] an electronic signature satisfies that rule of law” “A contract between business entities shall not be unenforceable.California Digital Signature Law Very broad. If a rule of law requires a signature [. nor inadmissible in evidence.. or allocate liability • “Attorneys Full Employment Act of 1997” .

US E-Sign Act Electronic Signatures in Global and National Commerce Act Massachusetts signature law taken to extremes • Signatures can be a “sound. Microsoft. sibling of UCITA. but also printed invoices) US E-Sign Act (ctd) Law is about electronic (rather than digital) signatures • Journalist who contacted the House discovered that the people involved in creating the Bill weren’t aware there was a difference • Bill was prepared with input from Dell. HewlettPackard. or process” – “Press 9 to sign a binding contract. symbol. opposed by the attorney generals of most states) by stealth . or 1 to hear this message again” – “Click here to enter into a legally binding agreement” • Online comparison shopping may cause problems because not buying is a “withdrawal of consent” – Enforceability will probably take a court case to decide • Vendors may charge extra for physical items (disk media. Gateway. and other vendors – No consumer advocacy groups were consulted • The finished Act appears to be a means of imposing UETA (Uniform Electronic Transactions Act. manuals.

German Digital Signature Law Like the Utah act. timestamping and directory service mechanisms. etc etc . based on public-key technology Requirements • Licensed CA’s which meet certain requirements – CA’s must provide a phone hotline for revocation • Identification is based on the German ID card – This type of identification isn’t possible in most countries – Allows pseudonyms in certificates • Key and storage media must be controlled only by the key owner – Key may be generated for user by the CA if strict controls are followed to ensure no copies are retained • Provisions for timestamping and countersigning German Digital Signature Law (ctd) Signatures from other EU countries are recognised provided an equivalent level of security is employed Multilevel law • Signaturgesetz (SigG) provides general framework – Defines digital signature – Defines role of a CA – Defines certificates and outlines how they’re handled • Signaturverordnung (SigV) – Sets out operational details and responsibilities of a CA • Signatur-Interoperabilitätspezifikation (SigI) – Technical specification to implement the SigG and SigV – Specifies data formats. algorithms.

000 per certificate) .German Digital Signature Law (ctd) Example • SigG: Private key must be protected • SigV: Private key must be protected in the following circumstances using certain technical measures • SigI: Here are the technical measures Details are set out in the implementation guidelines • Extremely detailed (over 300 pages) • Specifies things like – Hash and signature algorithms – Random number generation for keys – Personnel security – Directory and timestamping services • Criticised as being too detailed and complex to follow German Digital Signature Law (ctd) Case study: Telesec CA • • • • SigG/SigV-compliant CA $12M to set up 25 full-time staff 250 certificates issued (~$50.

and company name • Allows pseudonyms. date of birth. usage logged • CAs must be ISO 9000 certified • This severely limits the technology which can be used Italian Digital Signature Law (ctd) Signature mechanism must present the data to be signed in a clear and unambiguous manner. but this must be indicated in the cert and CA must record real identity Includes some bizarre requirements which are at odds with the way the rest of the world does things . this forces everyone to use smart cards for key management • The OS must be ITSEC F-C2/E2 or TCSEC C2 • Access to the system must be controlled. and ask for confirmation of signature generation • Allows for automated signature generation provided that this is “clearly connected to the will of the subscriber” Certificates must contain users name.Italian Digital Signature Law Similar to the German law. but all requirements are listed in one place • Minimum key size is 1024 bits Everything has to be certified to various ITSEC levels • Key generation devices must be certified to ITSEC E3 with a HIGH level of robustness – In practice. users identified.

this is a rather nice law which addresses most digital signature issues Swedish Electronic ID card (SEIS) Smart-card contains three keys • Authentication (= X. signature. substitute CA) Except for the fixation with (very expensive and complicated) security certification and some strange requirements for information in certificates. address. terms and conditions.509 “nonrepudiation”) • Encryption Card doubles as standard ID card (photo. contact details.Italian Digital Signature Law (ctd) CA must • • • • Verify that the key hasn’t been certified by another CA Verify that the users possesses the private key Publish certificates in LDAP directories Publish details on themselves (company name.509 “digital signature”) – Card supports a challenge-response protocol for authentication – Card signs a random challenge from the remote system • Digital signature (=X. etc) Cards are issued by • Government agencies • Financial institutions • Companies to their employees .

key management and protection • Key may be generated by CA for user provided strict controls are followed – Two-person security – No copy of key is retained by CA – PIN-protected device is physically handed to user by CA – User signs document acknowledging receipt – Activation PIN is delivered over separate channel – User is told to immediately change the PIN • Complex physical and procedural security procedures for cards Singapore Electronic Transactions Act Follows the one-sentence signature law model • Where the law requires a paper signature. physical and procedural security. security auditing.SEIS (ctd) Usage governed by the SEIS Certification Policy • Backdoor digital signature law • Covers certificate issuing process. an electronic one will do Offer of acceptance of contracts may be expressed electronically Signature apparatus must be under sole control of signer Certificate requirements • Cannot publish a certificate known to be false • Certificates must specify a reliance limit Compliant CAs are not liable for certificate problems .

special short-lived (1 day max) certificates • Vouch for a certain property of the user UNCITRAL Model Law on Electronic Commerce UN Comission on International Trade (UNCITRAL) model e-commerce law • Many acts and laws legislate a particular technology to provide reliance for digital signatures • The model law provides a general framework for electronic signatures without defining their exact form Later revisions may nail down precise forms for electronic signatures .ETSI Digital Signature Draft ETSI TR 101 specifies technical requirements for signatures • Role of signer (eg Financial director) is more important than the name • Signature must be dated to allow later dispute resolution References various standards efforts (eg PKIX) for further study Privilege attribute certificates (PACs) • Defined by ECMA.

UN Draft Articles on Electronic Signatures
Follows the one-sentence signature law model
• Includes a rationale for each point

Defines two levels of signature
• “Electronic signature” = data attached to a message to indicate a signers approval of the message • “Enhanced electronic signature” = electronic signature with extra constraints – Unique to the signature holder – Verifiable through a standard procedure – Under the sole control of the signer

Extremely broad and technology-independent Specifies (rather vague) reliance and obligation details

EU Directive on Electronic Signatures
Defines an electronic signature as linking signer and data, created by a means solely controlled by the signer (not necessarily a cryptographic signature) Precedes the directive itself with the intended aims of the directive Makes accreditation and licensing voluntary and nondiscriminatory
• No-one can be prevented from being a CA • Intent is to encourage best practices while letting the market decide

EU Directive on Electronic Signatures (ctd)
Electronic signature products must be made freely available within the EU Electronic signatures can’t be denied recognition just because they’re electronic Absolves CA’s of certain types of liability
• Provides for reliance limits in certificates

Recognises certificates from non-EU states issued under equivalent terms Allows for pseudonyms in certificates

EU Directive on Electronic Signatures (ctd)
Recognises that a regulatory framework isn’t needed for signatures used in closed systems
• Trust is handled via existing commercial relationships • Parties may agree among themselves on terms and conditions for electronic signatures • Keys may be identified by a key fingerprint on a business card or in a letterhead

Session-Level Security
PGP, ssh, S/WAN, satan & crack: Securing the internet by any means necessary — Don Kitchen

Session-level Security Overview
Most session security protocols use some variation of 1. Decide on security parameters 2. Establish shared secret to protect further communications 3. Authenticate the previous exchange

IP security — security built into the IP layer Provides host-to-host (or firewall-to-firewall) encryption and authentication Required for IPv6, optional for IPv4 Comprised of two parts:
• IPSEC proper (authentication and encryption) • IPSEC key management

Domain of interpretation (DOI) nails down the precise details for an application of IPSEC

IPSEC Architecture
Key management establishes a security association (SA) for a session
• SA used to provide authentication/confidentiality for that session • SA is referenced via a security parameter index (SPI) in each IP datagram header

Authentication header — integrity protection only Inserted into IP datagram:

Integrity check value (ICV) is 96-bit HMAC

AH (ctd)
Authenticates entire datagram:

Mutable fields (time-to-live, IP checksums) are zeroed before AH is added Sequence numbers provide replay protection
• Receiver tracks packets within a 64-entry sliding window

Encapsulating security protocol — authentication (optional) and confidentiality Inserted into IP datagram:

Contains sequence numbers and optional ICV as for AH

ESP (ctd)
Secures data payload in datagram:

Encryption protects payload
• Authentication protects header and encryption

SA bundling is possible
• ESP without authentication inside AH • Authentication covers more fields this way than just ESP with authentication

IPSEC Algorithms
DES in CBC mode for encryption HMAC/MD5 and HMAC/SHA (truncated to 96 bits) for authentication Later versions added optional, DOI-dependent algorithms
• • • • • • 3DES Blowfish CAST-128 IDEA RC5 Triple IDEA (!!!)

Use SPI to look up security association (SA) Perform authentication check using SA Perform decryption of authenticated data using SA Operates in two modes
• Transport mode (secure IP), protects payload • Tunneling mode (secure IP inside standard IP), protects entire packet – Popular in routers – Communicating hosts don’t have to implement IPSEC themselves – Nested tunneling possible

IPSEC Key Management ISAKMP • Internet Security Association and Key Management Protocol Oakley • DH-based key management protocol Photuris • DH-based key management protocol SKIP • Sun’s DH-based key management protocol Protocols changed considerably over time. Exchange cookies 2. Identify other party Authenticate data exchanged in steps 1 and 2 n. Firefly is the NSA’s key exchange protocol for STU-III secure phones Three-stage protocol 1. Change session keys or update security parameters . Use DH to establish a shared secret Agree on security parameters 3. most borrowed ideas from each other Photuris Latin for “firefly”.

stops flooding attacks • Attacker requests many key exchanges and bogs down host (clogging attack) Cookie depends on • IP address and port • Secret known only to host • Cookie = hash( source and dest IP and port + local secret ) Host can recognise a returned cookie • Attacker can’t generate fake cookies Later adopted by other IPSEC key management protocols Photuris (ctd) Client Client cookie    Server  Server cookie Offered schemes  DH keygen Chosen scheme DH keygen Client identity Authentication for previous data  Server identity Authentication for previous data .Photuris (ctd) Cookie based on IP address and port.

SKIP Each machine has a public DH value authenticated via • X.509 certificates • PGP certificates • Secure DNS Public DH value is used as an implicit shared key calculation parameter • Shared key is used once to exchange encrypted session key • Session key is used for further encryption/authentication Clean-room non-US version developed by Sun partner in Moscow • US government forced Sun to halt further work with non-US version Oakley Exchange messages containing any of • • • • Client/server cookies DH information Offered/chosen security parameters Client/server ID’s until both sides are satisfied Oakley is extremely open-ended. with many variations possible • Exact details of messages exchange depends on exchange requirements – Speed vs thoroughness – Identification vs anonymity – New session establishment vs rekey – DH exchange vs shared secrets vs PKC-based exchange .

Establish secure. authenticated channel (“SA”) 2.ISAKMP NSA-designed protocol to exchange security parameters (but not establish keys) • Protocol to establish. and delete IPSEC security associations • Provides a general framework for exchanging cookies. and key management and identification information • Exact details left to other protocols Two phases 1. security parameters. Negotiate security parameters (“KMP”) ISAKMP/Oakley ISAKMP merged with Oakley • ISAKMP provides the protocol framework • Oakley provides the security mechanisms Combined version clarifies both protocols. resolves ambiguities . modify.

ISAKMP/Oakley (ctd) Phase 1 example Client Client cookie  Client ID Key exchange information  Server cookie Server ID Key exchange information Server signature Client signature  Server Other variants possible (data spread over more messages. authentication via shared secrets) • Above example is aggressive exchange which minimises the number of messages ISAKMP/Oakley (ctd) Phase 2 example Client Encrypted. MAC’d Server nonce Security parameters accepted Encrypted. MAC’d Client nonce Server nonce  . MAC’d Client nonce Security parameters offered  Server  Encrypted.

SSL Secure sockets layer — TCP/IP socket encryption Usually authenticates server using digital signature Can authenticate client. broken by members of the audience while it was being presented SSLv2 shipped with Navigator 1. but this is never used Confidentiality protection via encryption Integrity protection via MAC’s Provides end-to-end protection of communications sessions History SSLv1 designed by Netscape. proposed for IETF standardisation • Never finalised.0 Microsoft proposed PCT: PCT != SSL SSLv3 was peer-reviewed. still exists only as a draft .

Negotiate the cipher suite 2. Establish a shared session key 3. Authenticate the server (optional) 4. fields Secure session  Server  Hello + optional certificate Client key exchange Change cipher + MAC of prev. Authenticate previously exhanged data SSL Handshake (ctd) Client Hello     Change cipher + MAC of prev. fields Secure session . Authenticate the client (optional) 5.SSL Handshake 1.

SSL Handshake (ctd) Client hello: • Client nonce • Available cipher suites (eg RSA + RC4/40 + MD5) Server hello: • Server nonce • Selected cipher suite Server adapts to client capabilities Optional certificate exchange to authenticate server/client • In practice only server authentication is used SSL Handshake (ctd) Client key exchange: • RSA-encrypt( premaster secret ) Both sides: • 48-byte master secret = hash( premaster + client-nonce + server-nonce ) Client/server change cipher spec: • Switch to selected cipher suite and key .

SSL Handshake (ctd) Client/server finished • MAC of previously exchanged parameters (authenticates data from Hello and other exchanges) – Uses an early version of HMAC Can reuse previous session data via session ID’s in Hello Can bootstrap weak crypto from strong crypto: • • • • Server has > 512 bit certificate Generates 512-bit temporary key Signs temporary key with > 512 bit certificate Uses temporary key for security Maintains separate send and receive states SSL Data Transfer .

NNTP.SSL Characteristics Protects the session only Designed for multiple protocols (HTTP.ssleay.org/ Server • Some variation of Apache + SSLeay Browser • Hacked US browser • Non-US browser SSL Proxy • Strong encryption tunnel using SSL . but most browsers US-sourced and crippled Strong SSL Encryption Most implementations based on SSLeay. http://www. POP3. FTP) but only really used with HTTP Compute-intensive: • 3 CPU seconds on Sparc 10 with 1Kbit RSA key • 200 MHz NT box allows about a dozen concurrent SSL handshakes – Use multiple servers – Use hardware SSL accelerators Crippled crypto predominates • Strong servers freely available (Apache). SMTP.

SSL3-RSA-WITH-RC4-128-MD5: SSL3-RSA-WITH-3DES-EDE-CBC-SHA: .net/ Patches Netscape (any version) to do strong encryption Original: POLICY-BEGINS-HERE: Software-Version: MAX-GEN-KEY-BITS: PKCS12-DES-EDE3: PKCS12-RC2-128: PKCS12-RC4-128: PKCS12-DES-56: PKCS12-RC2-40: PKCS12-RC4-40: ....0 1024 true true true true true true true true . SSL3-RSA-WITH-RC4-128-MD5: SSL3-RSA-WITH-3DES-EDE-CBC-SHA: . Cypherpunk policy Mozilla/4.Strong SSL Browsers Fortify. Export policy Mozilla/4... http://www..fortify.0 512 false false false false true true conditional conditional Strong SSL Browsers (ctd) Patched version POLICY-BEGINS-HERE: Software-Version: MAX-GEN-KEY-BITS: PKCS12-DES-EDE3: PKCS12-RC2-128: PKCS12-RC4-128: PKCS12-DES-56: PKCS12-RC2-40: PKCS12-RC4-40: ...

org/ • Based on open-source Netscape • Strong crypto added within one day of release from the US Exported US-only versions.Strong SSL Browsers (ctd) Opera. http://www.com/ • Norwegian browser.cryptozilla. some NT ports in progress SSL portion is somewhat painful to configure Howtos available on the net . http://www. uses SSLeay Cryptozilla.operasoftware.replay.com/pub/replay/pub/ • Contains copies of most non-exportable software Strong SSL Servers Based on SSLeay + some variant of Apache Mostly Unix-only. ftp://ftp.

Strong SSL Proxies Tunnel weak or no SSL over strong SSL SGC Server Gated Cryptography Allows strong encryption on a per-server basis Originally available only to “qualified financial institutions”.bank. later extended slightly (hospitals. some government departents) Requires special SGC server certificate from Verisign Enables strong encryption for one server (www.com) .

com/ietf-tls/ .consensus. http://www.1 Not finalised yet.SGC (ctd) Exportable SSL Client Hello Weak encryption key Weak encryption    Server  Hello + certificate Weak encryption SSL with SGC Client Hello Strong encryption key Strong encryption    Server  Hello + SGC certificate Strong encryption TLS Transport layer security IETF-standardised evolution of SSLv3 • Non-patented technology • Non-crippled crypto • Updated for newer algorithms Substantially similar to SSL • TLS identifies itself as SSL 3. little implementation support TLS standards work.

com/shttp/intro. available worldwide SSH v2 submitted to IETF for standardisation Can be up and running in minutes . http://www.S-HTTP Designed by Terisa in response to CommerceNet RFP. rlogin.fi/ssh/ Also allows port forwarding (tunneling over SSH) Built-in support for proxies/firewalls Includes Zip-style compression Originally implemented in Finland.html Predates SSL and S/MIME Security extension for HTTP (and only HTTP) Document-based: • (Pre-)signed documents • Encrypted documents Large range of algorithms and formats supported Not supported by browsers (or much else) SSH Originally developed in 1995 as a secure replacement for rsh.terisa.hut.cs. et al (ssh = secure shell). http://www.

eg SecurID Developed outside US. crippled crypto not even considered: • 1024 bit RSA long-term key • 768 bit RSA short-term key (has to fit inside long-term key for double encryption) • Triple DES session encryption (other ciphers available) . changed every hour Client Double-encrypted session key Encrypted data  Server  Long-term + short-term keys  Encrypted confirmation  Encrypted data Long-term server key binds the connection to the server Short-term encryption key makes later recovery impossible • Short-term keys regenerated as a background task SSH Authentication Multiple authentication mechanisms • Straight passwords (protected by SSH encryption) • RSA-based authentication (client decrypts challenge from server.SSH Protocol Server uses two keys: • Long-term server identification key • Short-term encryption key. returns hash to server) • Plug-in authentication mechanisms.

DNSSEC DNS name space is divided into zones. each zone has resource records (RR’s) Owner_name Type Class TTL Rdlength Rdata • Owner = name of node • Type = RR type – – – – – – A = Host address NS = authoritative name server CNAME = canonical name for alias SOA = start of zone authority PTR = domain name pointer MX = mail exchange • Class = IN (Internet) • TTL = time for which RR may be cached DNSSEC (ctd) Name servers hold zone information • Each zone has primary and secondary servers • Secondaries perform zone transfers to obtain new data from primaries Resolvers extract information from name servers • Cached entry is returned directly • Interative query returns referral to the appropriate server • Recursive query queries other server and returns result All of these points present security vulnerabilities .

signature on RR • NXT. chains from one name in a zone to the next – Allows authenticated denial of the existence of a name • These RR’s have signature start and end times. require coordinated clocks on hosts .DNSSEC (ctd) DNSSEC splits the service into name server and zone manager • Zone manager signs zone data • Name server publishes signed data – Compromise of name server doesn’t compromise DNSSEC Resolvers need to store at least one top-level zone key DNSSEC (ctd) RR’s are extended with new types • KEY. server public key • SIG.

DNSSEC (ctd) Transaction signature guarantees the response came from a given server • Signature covers query and response Also used for • Secure zone transfer • Secure dynamic update (replaces editing the zone’s master file) • Offline update – Uses authorising dynamic update key for update – Zone data is signed later with the zone key SNMP Security General SNMP security model: Block it at the router Authentication: hash( secret value + data ) Confidentiality: encrypt( data + hash ) Many devices are too limited to handle the security themselves • Handled for them by an element manager • Device talks to element manager via a single shared key Users generally use a centralised enterprise manager to talk to element managers • Enterprise manager is to users what element manager is to devices .

Email Security “Why do we have to hide from the police. son. Daddy?” “Because we use PGP. They use S/MIME” Email Security Problems with using email for secure communications include • Doesn’t handle binary data • Messages may be modified by the mail transport mechanism – Trailing spaces deleted – Tabs  spaces – Character set conversion – Lines wrapper/truncated • Message headers mutate considerably in transit Data formats have to be carefully designed to avoid problems .

Email Security Requirements Main requirements • Confidentiality • Authentication • Integrity Other requirements • • • • • • Non-repudiation Proof of submission Proof of delivery Anonymity Revocability Resistance to traffic analysis Many of these are difficult or impossible to achieve Security Mechanisms Detached signature: • Leaves original message untouched • Signature can be transmitted/stored seperately • Message can still be used without the security software Signed message • Signature is always included with the data .

Security Mechanisms (ctd) Encrypted message Usually implemented using public-key encryption Mailing lists use one public-key encrypted header per recipient • Any of the corresponding private keys can decrypt the session key and therefore the message Security Mechanisms (ctd) Countersigned data Encrypted and signed data • Always sign first. then encrypt S( E( “Pay the signer $1000” )) vs E( S( “Pay the signer $1000” )) .

x. MIME. this wasn’t easy Attempt to build a CA hierarchy along X. PEM Protection Types Unsecured data Integrity-protected (MIC-CLEAR) • MIC = message integrity check = digital signature Integrity-protected encoded (MIC-ONLY) Encrypted integrity-protected (ENCRYPTED) General format: -----BEGIN PRIVACY-ENHANCED MESSAGE----Type: Value Encapsulated header Type: Value Type: Value Blank line Data Encapsulated content -----END PRIVACY-ENHANCED MESSAGE----- ... this wasn’t easy Solved the data formatting problem with base64 encoding • Encode 3 binary bytes as 4 ASCII characters • The same encoding was later used in PGP 2.500 available.500 lines • Without X.PEM Privacy Enhanced Mail. . 1987 Attempt to add security to SMTP (MIME didn’t exist yet) • Without MIME to help.

MIC-ONLY Content-Domain: RFC822 Originator-Certificate: MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV BAoTF1JTQSDRiNKcOCaCoLAyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCFNOrDDExDzAN .RSA.PEM Protection Types (ctd) MIC-ONLY -----BEGIN PRIVACY-ENHANCED MESSAGE----Proc-Type: 4.. dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQReSIsTKEYeSCrOWizEs5wUJ35a5h MIC-Info: RSA-MD5..RSA. jV2OfH+nnXFNorDL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6 EtE7K2QDeVMCyXsdJlA8fA== LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo= -----END PRIVACY-ENHANCED MESSAGE----- PEM Protection Types (ctd) ENCRYPTED -----BEGIN PRIVACY-ENHANCED MESSAGE----Proc-Type: 4. 5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w== Issuer-Certificate: MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV .. iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/ 5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w== Issuer-Certificate: MIIB3FNoRDgCAQowDQYJKoZIhvcNAQECBQAwTzEWiGEbLUMenKraFTMxIDAeBgNV BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL ...BFF968AA74691AC1 Originator-Certificate: MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV ... UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG Continues . EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h MIC-Info: RSA-MD5..ENCRYPTED Content-Domain: RFC822 DEK-Info: DES-CBC.

O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv 7x0Z3Jx2vTAhOYHMcqqCjA== qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA== -----END PRIVACY-ENHANCED MESSAGE----- PEM CA Hierarchy Hierarchy allows only a single path from the root to the end entity (no cross-certificates) Although PEM itself failed.66 Key-Info: RSA. the PEM CA terminology still crops up in various products .PEM Protection Types (ctd) Continued Recipient-ID-Asymmetric: MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=.

drug tests for users.500 names – Actually. noone uses X.PEM CA Hierarchy (ctd) Policy CA’s guarantee certain things such as uniqueness of names • High-assurance policies (secure hardware. it was hideously expensive • CA’s job was made so onerous noone wanted it – Later versions made it easier .500 names • CA’s for commercial organisations and universities can’t meet the same requirements as government defence contractors for high-assurance CA’s – Later versions of PEM added lower-assurance CA hierarchies to fix this • CA hardware was always just a few months away – When it arrived. etc) – Can’t issue certificates to anything other than other highassurance CA’s • Standard CA’s • No-assurance CA’s (persona CA’s) – Certificate vending machines – Clown suit certificates Why PEM Failed Why the CA’s failed • The Internet uses email addresses. not X.

modified for MIME-like content types PGP Pretty Good Privacy • Hastily released in June 1991 by Phil Zimmerman (PRZ) in response to S.500 support infrastructure never materialised • RSA patent problems Pieces of PEM live on in a few European initiatives • MailTrusT.266 • MD4 + RSA signatures and key exchange • Bass-O-Matic encryption • LZH data compression • uuencoding ASCII armour • Data format based on a 1986 paper by PRZ PGP was immediately distributed worldwide via a Usenet post .Why PEM Failed (ctd) • Hierarchy enshrined the RSADSI monopoly – CA hardware acted as a billing mechanism for RSA signatures – People were reluctant to trust RSADSI (or any one party) with the security of the entire system Why the message format failed • The PEM format was ugly and intrusive – PEM’s successors bundled everything into a single blob and tried to hide it somewhere out of the way • The reqired X. SecuDE.

0 • Bass-O-Matic was weak. Atari. VMS added • Internationalisation support added Legal Problems PGP has been the centre of an ongoing legal dispute with RSADSI over patents • RSADSI released the free RSAREF implementation for (noncommercial) PEM use • PGP 2. Amiga.6 was altered to use RSAREF in the US • Commercial versions were sold by Viacrypt.0 lead to an international effort to develope 2.PGP (ctd) PGP 1. who have an RSA license Later versions deprecated RSA in favour of the nonpatented Elgamal • Elgamal referred to in documentation as Diffie-Hellman for no known reason . replaced by the recently-developed IDEA • MD4 " " " " MD5 • LZH replaced by the newly-developed InfoZip (now zlib) • uuencoding replaced with the then-new base64 encoding • Ports for Unix.

eg: 26 February 1995: San Francisco Examiner and SF Chronicle publish an article criticising the governments stand on encryption and the PGP investigation 27 February 1995: Author of article subpoena’d to appear before the Grand Jury Investigation dropped in January 1996 with no charges laid PGP Message Formats Unsecured Compressed Signed/clearsigned Encrypted + optional encoding General format -----BEGIN PGP message type----data -----END PGP message type----- .Government Problems In early 1993. someone apparently told US Customs that PRZ was exporting misappropriated crypto code US Customs investigation escalated into a Federal Grand Jury (US Attorney) in September 1993 US government was pretty serious.

3 iQCVAgUBK9IAl2v14aSAK9PNAQEvxgQAoXrviAggvpVRDLWzCHbNQo6yHuNuj8my cvPx2zVkhHjzkfs5lUW6z63rRwejvHxegV79EX4xzsssWVUzbLvyQUkGS08SZ2Eq bLSuij9aFXalv5gJ4jB/hU40qvU6I7gKKrVgtLxEYpkvXFd+tFC4n9HovumvNRUc ve5ZY8988pY= =NOcG -----END PGP SIGNATURE----Yours is next.PGP Message Formats (ctd) Clearsigned message: -----BEGIN PGP SIGNED MESSAGE----We've got into Peters presentation. useless.3a hQEMAlkhsM216BqRAQf/f938A6hglX51/hwa42oCdrQDRGw6HJd+5OqQX/58JB8Y UAlrYBHYZ5md46ety62phvbwfsNuF9igSx2943CHrnuIVtkSXZRpKogtSE1oMfab 5ivD4I+h3Xk0Jpkn5SXYAzC6/cjAZAZSJjoqy28LBIwzlfNNqrzIuEW8lbLPWAt1 eqdS18ukiOUvnQAI1QfJipGUG+Db1KnpqJP7wHUl/4RG1Qi50p3BCDIspC8jzQ/y GsKFlckA132dMx6b80vsUZga/tmJOwrgBjSbnOJ8UzLrNe+GjFRyBS+qGuKgLd9M ymYgMyNOqo/LXALSlLIcz3inDSC5NJj04RbRZ00w4KYAAFrxX9a1BQq1nb40/OSB CgrPqi61jBks2NW2EPoIC7nV5xLjflZwlRjY/V5sZS6XDycJ9YOf6fOclNwCoBsB HRshmNtMHH2tq2//OozKZ8/GHGNysN8QQWNQYElgRCgH3ou1E+CJoyoPwrMqjSYC oGp4fezQpiI83Ve/QMMV276KntTFLRpQ2H+lLDvX9Wfjg1+xTw== =ZuOF -----END PGP MESSAGE----- . -----BEGIN PGP SIGNATURE----Version: 2. Resistance is PGP Message Formats (ctd) Anything else -----BEGIN PGP MESSAGE----Version: 2.

PGP Key Formats Unlike PEM. PGP also defined public/private key formats • Key trust = how much the key is trusted to sign things (set by user) • userID trust = how much the userID is trusted to belong to this key • Signing trust = copy of the signing keys trust PGP calculates userID trust = sum of signing trusts PGP Trust UserID trust = trust of binding between userID and key Key trust = trust of key owner Example: UserID = Politician • UserID trust = High • Key trust = Low Trust levels • • • • Unknown None Casual Heavy-duty .

the web of trust doesn’t really deliver • It can also be used hierarchically. like X. trust = none Keys are revoked with a signed revocation which PGP adds to the key .PGP Trust (ctd) Trust levels are automatically computed by PGP User can define the required trust levels (eg 3 casuals = 1 high) PGP Trust (ctd) In practice.509 Each key can contain multiple userID’s with their own trust levels • userID = Peter Gutmann. trust = high • userID = University Vice-Chancellor.

mail) • PGP key fingerprint designed for this purpose First-generation keyservers • email/HTTP interface to PGP keyring Second-generation keyservers • LDAP kludged to handle PGP ID’s . phone.PGP Keyrings One or more keys stored together constitute a keyring Keys are looked up by • userID (free-form name) • keyID (64-bit value derived from the public key) The owners key is ultimately trusted and can convey this to other keys Key Distribution Key distribution doesn’t rely on an existing infrastructure • Email • Personal contact – Keysigning services • Mailed floppies Verification by various out-of-band means (personal contact.

reduces message overhead .PGP Key Problems KeyID is 64 least significant bits of public key • Can construct keys with arbitrary ID’s • Allows signature spoofing Key fingerprints can also be spoofed Advantages of PGP over PEM You can pick your own name(s) You don’t have to register with an authority PGP requires no support infrastructure The trust mechanism more closely matches real life Certificate distribution can be manual or automatic (just include it with the message) PGP is unique among email security protocols in having no crippled encryption PGP’s compression speeds up encryption and signing.

boundary="Boundary" Content-Transfer-Encoding: base64 --Boundary encryption info --Boundary message --Boundary signature --Boundary-- Both PEM and PGP were adapted to fit into the MIME framework .MIME-based Security Multipurpose Internet Mail Extensions Provides a convenient mechanism for transferring composite data Security-related information sent as sections of a multipart message • multipart/signed • multipart/encrypted Binary data handled via base64 encoding MIME-aware mailers can automatically process the security informtion (or at least hide it from the user) MIME-based Security (ctd) General format: Content-Type: multipart/type.

micalg="rsa-md5". UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG --Signed Message-- .RSA.MOSS MIME Object Security Services • PEM shoehorned into MIME • MOSS support added to MIME types via application/mosssignature and application/moss-keys MOSS (ctd) MOSS Signed Content-Type: multipart/signed. protocol="application/mosssignature". --Signed Message Content-Type: application/moss-signature Version: 5 Originator-ID: jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6 EtE7K2QDeVMCyXsdJlA8fA== MIC-Info: RSA-MD5. boundary="Signed Message" --Signed Message Content-Type: text/plain Support PGP: Show MOSS to your friends.

’ -----BEGIN PGP MESSAGE----becomes .BFF968AA74691AC1 Recipient-ID: MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=. protocol="application/moss-keys".MOSS (ctd) MOSS Encrypted Content-Type: multipart/encrypted. boundary="Encrypted Message" --Encrypted Message Content-Type: application/moss-keys Version: 5 DEK-Info: DES-CBC. O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv 7x0Z3Jx2vTAhOYHMcqqCjA== --Encrypted Message Content-Type: application/octet-stream qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA== --Encrypted Message-- PGP/MIME PGP shoehorned into MIME • PGP support added to MIME types via application/pgpsignature and application/pgp-encrypted PGP already uses ‘--’ so PGP/MIME escapes this with ‘.-----BEGIN PGP MESSAGE----- .66 Key-Info: RSA.

PGP/MIME (ctd) PGP/MIME Signed: Content-Type: multipart/signed.2 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI= =ndaj .-----END PGP MESSAGE------Signed-- PGP/MIME (ctd) PGP/MIME Encrypted Content-Type: multipart/encrypted. boundary=Encrypted --Encrypted Content-Type: application/pgp-encrypted Version: 1 --Encrypted Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----Version: 2.6.2 hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3 1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8= =zzaA -----END PGP MESSAGE------Encrypted-- . boundary=Signed --Signed Content-Type: text/plain Our message format is uglier than your message format! --Signed Content-Type: application/pgp-signature .6. protocol="application/pgpencrypted". protocol="application/pgp-signature".-----BEGIN PGP MESSAGE----Version: 2. micalg=pgp-md5.

Public Key Cryptography Standards – RC2. RC4 for data encryption – PKCS #1. for key exchange – PKCS #7. RSA encryption.MOSS and PGP/MIME MOSS never took off PGP/MIME never took off either S/MIME Originally based on proprietary RSADSI standards and MIME • PKCS. for message formatting Newer versions added non-proprietary and non-patented ciphers . cryptographic message syntax.

CMS Cryptographic Message Syntax • Type-and-value format Data content types • • • • • • Data Signed data Encrypted data (conventional encryption) Enveloped data (PKC-encrypted) Digested (hashed) data Authenticated (MAC’d) data CMS (ctd) Other content types possible • Private keys • Key management messages Content can be arbitrarily nested .

Signed Data Format Digest (hash) algorithm(s) Encapsulated data Signer certificate chain(s) Signature(s) Presence of hash algorithm information before the data and certificates before the signatures allows one-pass processing Signature Format Signing certificate identifier Authenticated attributes Signature Unauthenticated attributes Authenticated attributes are signed along with the encapsulated content • Signing time • Signature type – “I agree completely” – “I agree in principle” – “I disagree but can’t be bothered going into the details” – “A flunky handed me this to sign” .

Signature Format (ctd) • Receipt request • Security label • Mailing list information Unauthenticated attributes provide a means of adding further information without breaking the original signature • Countersignature – Countersigns an existing signature – Signs signature on content rather than content itself. so other content doesn’t have to be present – Countersignatures can contain further countersignatures Enveloped Data Format Per-recipient information Key management certificate identifier Encrypted session key Newer versions add support for key agreement algorithms and previously distributed shared conventional keys .

http://www.CMS  S/MIME Wrap each individual CMS layer in MIME base64 encode + wrap content Encode as CMS data base64 encode + wrap content Encode as CMS signed data base64 encode + wrap content Encode as CMS enveloped data base64 encode + wrap content Result is 2:1 message expansion S/MIME Problems Earlier versions used mostly crippled crypto • Only way to interoperate was 40-bit RC2 – RC2/40 is still the lowest-common-denominator default – User is given no warning of the use of crippled crypto – Message forwarding may result in security downgrade • S/MIME-cracking screen saver released in 1997. rejected by IETF as a standard IETF developed S/MIME v3 using strong crypto and nonpatented.counterpane. non-proprietary technology .html – Performs optimised attack using RC2 key setup cycles – Looks for MIME header in decrypted data Original S/MIME based on patented RSA and proprietary RC2.com/smime.

receiver. MSP requires only trusted endpoints • MSP later used with MIME MSP Services Services provided • • • • • Authentication Integrity Confidentiality Non-repudiation of origin (via message signature) Non-repudiation of delivery (via signed receipts) MSP also provides rule-based access control (RBAC) based on message sensitivity and classification levels of sender.MSP Message Security Protocol.400 message contains envelope + content • MSP encapsulates X.400 MTA.400 content and adds security header X. and workstation • Receiving MUA checks that the receiver and workstation are cleared for the messages security classification • MSP rule-based access control (RBAC)  role-based access control (also RBAC) . used in Defence Messaging System (DMS) • X.400 security required using (and trusting) X.

integrity. RBAC • Sign + encrypt using either signature and key management certificates or dual-key certificate Any of the above can be combined with MSP signatures .MSP Certificates MSP defines three X. integrity. RBAC • Encrypted with key management or dual-key certificate Non-repudiation + confidentiality.509 certificate types • Signature-only • Encryption (key management) only • Signature and encryption (two keys in one certificate) Certificate also includes RBAC authorisations MSP Protection Types MSP Signature • MUA/MLA signs with signature-only certificate Non-repudiation • User signs with signature or dual-key certificate Confidentiality.

MSP Protection Types (ctd) MSP signature covers MSP header and encapsulated content • Mandatory for mailing lists User signature covers encapsulated content and receipt request information MSP Message Format Originator security data Originator key management cert chain Encrypted RBAC information (additional to per-recipient RBAC info) Signature Receipt request information Signature on encapsulated data and receipt info Signature cert chain Recipient security data Per-recipient Key management certificate identifier (KMID) Encrypted security classification(s) (RBAC) + secret key Mailing list control information MUA or MLA Signature Encapsulated content • RBAC is encrypted to protect it if no signatures are used .

MSP in Practice MSP is heavily tied into Fortezza hardware • DSA signatures • KEA key management • Skipjack encryption MSP later kludged to work with MIME a la MOSS and PGP/MIME .

Authentication “What was your username again?” clickety clickety — The BOFH User Authentication Basic system uses passwords • Can be easily intercepted Encrypt/hash the password • Can still intercept the encrypted/hashed form Modify the encryption/hashing so the encrypted/hashed value changes each time (challenge/response mechanism) .

User Authentication (ctd) Vulnerable to offline password guessing (attacker knows challenge and encrypted challenge. can try to guess the password used to process it) User Authentication (ctd) There are many variations of this mechanism but it’s very hard to get right • Impersonation attacks (pretend to be client or server) • Reflection attacks (bounce the authentication messages elsewhere) • Steal client/server authentication database • Modify messages between client and server • Chess grandmaster attack .

can’t perform a password-guessing attack • Requires reversible encryption Something similar is used by protocols like Kerberos Unix Password Encryption Designed to resist mid-70’s level attacks Uses 25 iterations of modified DES Salt prevents identical passwords from producing the same output . re-encrypts it with K.Simple Client/Server Authentication Client and server share a key K • Server sends challenge encrypted with K – Challenge should generally include extra information like the server ID and timestamp • Client decrypts challenge. transforms it (eg adds one. flips the bits). and sends it to the server • Server does the same and compares the two Properties • Both sides are authenticated • Observer can’t see the (unencrypted) challenge.

second half is 0xAAD3B435B51404EE Result is zero-padded(!) and used as 3 independant DES keys 8-byte challenge from server is encrypted once with each key 3  8-byte value returned to server Newer versions of NT added NTHASH (MD4 of data).crypt16 Handles 16 characters instead of 8 • 20 DES crypts for the first 8 • 5 DES crypts for the second 8 Result was weaker than the original crypt • Search for passwords by suffix • Suffix search requires only 5 DES crypts LMHASH From MS LAN Manager Like crypt16 but without the salt • • • • If password < 7 chars. but LMHASH data is still sent alongside NTHASH data Subject to rollback attacks (“I can’t handle this. give me LMHASH instead”) .

com/l0phtcrack/ • Collects hashed passwords via network sniffing. or from SAM file on disk • Two attack types – Dictionary search: 100.l0pht. from the registry.LMHASH (ctd) l0phtcrack.000 words in a few minutes on a PPro 200 – Brute force: All alphabetic characters in 6 hours. all alphanumerics in 62 hours on quad PPro 200 • Parallel attacks on multiple users • Runs as a background process NT Domain Authentication Joining • Client and server exchange challenges CC and SC • Session key = CC + CS encrypted with the machine password (NTHASH of LMHASH of machine name) • Result is used as RC4 key Anyone on the network can intercept this and recover the initial key . http://www.

profile. SID) aren’t authenticated This is why NT 5 will use Kerberos Attacking Domain Authentication over the Net Create a web page with an embedded (auto-loading) image • Image is held on an SMB Lanman server instead of an HTTP server • NT connects to server • Server sends fixed all-zero challenge • NT responds with the username and hashed password All-zero challenge allows the use of a precomputed dictionary . can be recoverd in the standard manner for a stream cipher Auxiliary data (logon script.NT Domain Authentication (ctd) User logon • Client sends RC4-encrypted LMHASH and NTHASH of user password • Server decrypts and verifies LMHASH and NTHASH of password RC4 key is reused.

challenge ) • Server stores (server-dependant) inner hash – Not vulnerable to server compromise because of serverID/salt Netware 4 added public-key encryption managed via the Netware Directory Services (NDS) .Attacking Domain Authentication over the Net (ctd) Reflection attack • • • • NT connects to the server as before Server connects back to NT NT sends challenge to server. server bounces it back to NT NT responds with the username and hash. server bounces it back to NT Server has now connected to the NT machine without knowing the password Netware Authentication Netware 3 used challenge-response method • Server sends challenge • Client responds with MD4( MD4( serverID/salt. password ).

accessed with a modification of the V3 protocol • Server sends challenge • Client responds with server-public-key encrypted V3 hash and session key • Server returns users RSA key encrypted with the session key Once the user has their RSA key pair on the workstation.Netware Authentication (ctd) Users public/private keys are stored by NDS. they can use it for further authentication • RSA key is converted to short-term Gillou-Quisquater (GQ) key • RSA key is deleted • GQ key is used for authentication Netware Authentication (ctd) Compromise of GQ key doesn’t compromise the RSA key GQ is much faster than RSA for both key generation and authentication GQ is used to authenticate the user • Sign request with short-term GQ key • Authenticate GQ key with long-term RSA key (from NDS) All valuable information is deleted as quickly as possible • Only the short-term GQ key remains active .

server decrypts ticket to recover client ID and session key – Only the client can recover the client-encrypted session key – Only the server can recover the server-encrypted session key .Kerberos Designed at MIT based on late-70’s work by Needham and Schroeder Relies on key distribution centre (KDC) to perform mediated authentication KDC shares a key with each client and server Kerberos (ctd) When a client connects to a server • KDC sends to client – Session key encrypted with clients key – Session key + client ID encrypted with servers key • User forwards the latter (a ticket) to the server • User decrypts session key.

Kerberos (ctd) Ticket identifies the client and clients network address (to stop it being used elsewhere) To avoid long-term password storage. the users password is converted to a short-term client key via the KDC • KDC sends a short-term client key encrypted with the users password to the client • User decrypts the short-term client key. decrypts the password • Future KDC  client communications use the short-term client key Kerberos (ctd) KDC also sends out a ticket-granting ticket (TGT) • TGT contains the client short-term key encrypted with the KDC key • Based on a theoretical Kerberos model which separates the authentication server and ticket-granting server – KDC/AS issues the TGT to talk to the KDC/TGS .

making replication easier Kerberos Realms Problems with a single KDC database • Compromising a KDC can compromise many users • Big KDC databases are difficult to manage • Big databases lead to name clashes Solution is to use multiple realms Interrealm authentication is just an extension of the standard Kerberos authentication mechanism .Mutual Authentication Parties exchange session-key encrypted timestamps • Only holders of the shared session key can get the encryption right • Replays detected by checking the timestamp on each exchange • Messages older than a certain time are automatically rejected KDC’s can be replicated to increase availability • Kerberos is designed so that most database accesses are readonly.

Kerberos Realms (ctd) When a client connects to a server in another realm • KDC authenticates client to other realm’s KDC • Other realm’s KDC authenticates client to other realm’s server Multi-KDC chaining is disallowed for security reasons (a rogue KDC in the chain could allow anyone in) Kerberos V5 Extended V4 in various ways • • • • • Extended ticket lifetimes (V4 max = 21 hours) Allowed delegation of rights Allowed heirarchical realms Added algorithms other than DES V4 used ad hoc encoding.1 . V5 used ASN.

Ticket Lifetimes V4 allowed maximum 21 hour lifetime. V5 allows specification of • Start time • End time • Renewal time (long-term tickets must be renewed periodically) This added flexibility by providing features like postdated tickets Delegation Request a TGT for different machine(s) and/or times TGT can be set up to allow forwarding (converted for use by a third party) and proxying (use on a machine other than the one in the TGT) Delegation is a security hole. Kerberos makes it optional TGT’s are marked as forwarded or proxied to allow them to be rejected .

com  hacker.com  bar.com ( server) Realms (ctd) Requires trusting KDC’s • Trusted chain only goes back one level • Current KDC can alter ID of previous KDC’s Kerberos abdicates responbility for trust in chaining to application developers (who will probably get it wrong) When chaining.com  bar.Realms V4 required a KDC to be registered in every other realm V5 (tries to) fix the problem with rogue KDC chaining by including in the ticket all transited realms (client ) foo. use the shortest path possible to limit the number of KDC’s in the path which must be trusted .com ( server) vs (client ) foo.

Other Changes in V5 V4 used DES. only the initiator can do this) • Encryption is CDMF (40-bit DES) . V5 added MD4 and MD5 V4 allowed offline password-guessing attacks on TGT’s • Request a TGT for the victim • Try passwords on the TGT V5 adds pre-authentication data to the TGT request Kerberos-like Systems KryptoKnight (IBM) • Closer to V4 than V5 • Can use random challenges instead of synchronised clocks • Either party can contact the KDC (in Kerberos.

Kerberos-like Systems (ctd) SESAME (EU) • European Kerberos clone mostly done by ICL. Bull. and Siemens – Uses XOR instead of DES – XOR in CBC mode cancels out 50% of the “encryption” – Keys are generated from the current system time – Only the first 8 bytes of data are authenticated • Apparently users were expected to find all the holes and plug in their own secure code • Later versions added public-key encryption support • Vendor-specific versions provided enhanced security services Kerberos-like Systems (ctd) DCE (OSF) • Distributed Computing Environment uses Kerberos V5 as a security component • DCE adds privilege and registration servers to the Kerberos KDC – Privilege server provides a universal unique user ID and group ID (Kerberos uses system-specific names and ID’s) – Registration server provides the database for the KDC and privilege server • DCE security is based on ACL’s (access control lists) for users and groups • Data exchanges are protected via native DCE RPC security .

but needs to be compensated for clock drift • Proprietary ACE server protocol will be replaced by RSAbased SecurSight in early ‘99 . produces 6-8 digit output (cardcode) – Card can be protected by 4-8 digit PIN which is added to the cardcode • Server does the same and compares the result • Timestamp provides automatic replay protection. sent to server in place of password – 64-bit key (seed). 64-bit time.Authentication Tokens Physical device used to authenticate owner to server Two main types • Challenge-response calculators • One-way authentication data generators – Non-challenge-response nature fits the “enter name and password” authentication model Authentication Tokens (ctd) SecurID • Uses clock synchronised with server • Token encrypts the time.

Authentication Tokens (ctd) Challenge-response calculators • • • • Encrypt a challenge from the server and return result to server Server does the same and compares the result Encryption is usually DES Encryption key is random (rather than a fixed password) which makes offline password guessing much harder Authentication Tokens (ctd) Possible attacks • Wait for all but the last character to be entered. then sieze the link • Hijack the session after the user is authenticated However. any of these are still vastly more secure than a straight password • It’s very difficult to choose an easy-to-guess password when it’s generated by crypto hardware • It’s very difficult to leak a password when it’s sealed inside a hardware token .

verifies that hash( n-1 ) = n S/Key (ctd) Knowing hash( hash( password )) doesn't reveal hash( password ) Values are transmitted as 16 hex digits or 6-word phrases Later refinements added new algorithms. more rigorous definitions of the protocol .S/Key One of a class of software tokens/one-time-password (OTP) systems Freely available for many OS’s.yak.net/skey/ Uses a one-way hash function to create one-time passwords • pass3 = hash( hash( hash( password ))) • pass2 = hash( hash( password )) • pass1 = hash( password ) – Actual hash includes a server-specific salt to tie it to a server Each hash value is used only once • Server stores value n. http://www.

nrl.OPIE One-time Passwords in Everything.mil/pub/security/opie/ Enhancement of S/Key with name change to avoid trademark problems PPP PAP/CHAP Simplest PPP authentication is PAP. ftp://ftp. developed by (US) Naval Research Laboratory Freely available for many OS’s. password authentication protocol • Plaintext user name + password Challenge handshake protocol was created to fix PAP • Standard challenge/response protocol using a hash of challenge and shared secret .navy.

Other PAP Variants SPAP • Shiva {Propietary|Password} Authentication Protocol • PAP with a few added bells and whistles ARAP • Appletalk Remote Access Protocol • Bidirectional challenge/response using DES – Authenticates client to server. server to client MSCHAP • • • • Microsoft CHAP DES-encrypts 8-byte challenge using LMHASH/NTHASH Server stores the hash rather than the plaintext password Subject to the usual LMHASH attacks RADIUS Remote authentication for dial-in user service Provides an authentication server for one or more clients (dial-in hosts) Client communicates with RADIUS server via encrypted communications using a shared secret key .

logging. returns authorisation response XTACACS. telnet . eg CHAP) • If challenge-response is used. user sends response to client. client forwards challenge to user.RADIUS (ctd) RADIUS protocol: • Client forwards user access request to RADIUS server • Server replies with – Reject access – Allow access (based on password) – Challenge (for challenge-response protocol. later documented and extended by Cisco • Forwards username and password to TACACS server. which forwards it to server One RADIUS server may consult another (acting as a client) TACACS/XTACACS/TACACS+ Based on obscure ARPANET access control system for terminal servers. extended authorisation • Can independantly authorise access via PPP. SLIP. Extended TACACS • Adds support for multiple TACACS servers.

• Separation of authentication, authorisation, and accounting functions with extended functionality • Password information is encrypted using RADIUS-style encryption • Password forwarding allows use of one password for multiple protocols (PAP, CHAP, telnet) • Extensive accounting support (connect time, location, duration, protocol, bytes sent and received, connect status updates, etc) • Control over user attributes (assigned IP addresse(s), connection timeout, etc)

Sorting out the xxxxxS’s
RADIUS, TACACS = Combined authentication and authorisation process XTACACS = Authentication, authorisation, and accounting separated TACACS+ = XTACACS with extra attribute control and accounting Common shortcomings
• No integrity protection • No replay protection • Packets leak data due to fixed/known formatting

ANSI X9.26
Sign-on authentication standard (“Financial institution sign-on authentication for wholesale financial transmission”) DES-based challenge-response protocol
• Server sends challenge (TVP = time variant parameter) • Client responds with encrypted authentication information (PAI = personal authentication information) XOR’d with TVP

Offline attacks prevented using secret PAI Variants include
• Two-way authentication of client and server • Authentication using per-user or per-node keys but no PAI

Public-key-based Authentication
Simple PKC-based challenge/response protocol
• Server sends challenge • Client signs challenge and returns it • Server verifies clients signature on the challenge

Vulnerable to chosen-protocol attacks
• Server can have client sign anything • Algorithm-specific attacks (eg RSA signature/encryption duality)

FIPS 196
Entity authentication using public key cryptography Extends and clarifies ISO 9798 entity authentication standard Signed challenge/response protocol:
• • • • Server sends server nonce SN Client generates client nonce CN Client signs SN and CN and returns to server Server verifies signature on the data

FIPS 196 (ctd)
Mutual authentication uses a three-pass protocol
• Server sends client signed SC as final step

Inclusion of CN prevents the previous chosen-protocol attacks
• Vulnerable to other attacks unless special precautions are taken

Capture data via cameras or microphones Verification is relatively easy, identification is very hard Fingerprints
• Small and inexpensive • ~10% of people are difficult or impossible to scan • Associated with criminal identification

Voice authentication
• Upset by background noise, illness, stress, intoxication • Can be used over phone lines

Eye scans
• Intrusive (scan blood vessels in retina/patterns in iris)

Biometrics (ctd)
• Everyone carries their ID on them • Very hard to forge • Easy to use

• You can’t change your password • Expensive • No real standards (half a dozen conflicting ones as well as vendor-specific formats) • User acceptance problems

Pluggable Authentication Modules OSF-designed interface for authentication/identification plugins Administrator can configure authentication for each application Service
login ftp telnet su

pam_unix.so pam_skey.so pam_smartcard.so pam_securid.so

PAM (ctd)
Modules are accessed using a standardised interface
pam_start( &handle ); pam_authenticate( handle ); pam_end( handle );

Modules can be stacked to provide single sign-on
• User is authenticated by multiple modules at sign-on – Avoids the need to manually invoke each sign-on service (kinit, dce_login, dtlogin, etc) • Password mapping allows a single master password to encrypt per-module passwords

PAM in Practice
A typical implementation is Linux-PAM
• Extended standard login (checks time, source of login, etc) • .rhosts, /etc/shells • • • • • • cracklib (for password checking) DES challenge/response Kerberos S/Key, OPIE RADIUS SecurID

Electronic Commerce
SET is the answer, but you have to phrase the question very carefully

Electronic Payments
An electronic payment system needs to be
• • • • • Widely recognised Hard to fake Hold its value Convenient to use Anonymous/not anonymous

Convenience is the most important point

Cheques Merchant doesn’t know whether the cheque is valid until it’s cleared Cheques (ctd) Consumer can’t detect fraud until the statement arrives Cost of processing errors vastly outweighs the cost of normal actions .

banks with cheques don’t .Credit Cards Authentication is online Settlement is usually offline (batch processed at end of day) Credit Cards (ctd) Consumer can’t detect fraud until the statement arrives Cost of processing errors vastly outweighs the cost of normal actions Merchant carries the risk of fraud in card not present transactions Consumer liability is limited to $50 Far more merchant fraud than consumer fraud Credit card companies assume liability for their merchants.

Transactions on the Internet Transactions are fairly conventional card not present transactions and follow the precedent set by phone orders Online nature provides instant verification Biggest problems are authentication and confidentiality General Model of Internet Transactions Virtually all net payment systems consist of some variant of this Everyone wants to be the middleman .

you can’t beat a credit card over SSL Business customers will buy to reduce current costs Payment Systems Book entry systems • • • • • • Credit cards over SSL Encrypted credit cards (Cybercash) Virtual credit cards (First Virtual) e-cheques (Netcash) Mondex/SET Many.Retail vs Business-to-business Commerce Retail commerce • Small dollar amounts • Stranger-to-stranger transactions Business-to-business commerce • Large dollar amounts • Based on trust relationships • Banks play a direct role — they guarantee the transaction – You can’t disintermediate the banks Business-to-business commerce is where the money is • For retail transactions. many others Bearer certificate systems • Scrip (Millicent) • True digital cash (Digicash) .

Netcash e-cheques.com .com/~netcash Cybercash Encrypted credit cards. http://www. http://www.cybercash.teleport.

Some options are • Don’t handle micropayments at all • Middleman has to act as a bank • Use a betting protocol: 10 cent transaction = 1% chance of a $10 transaction Digicash Digicash issuing protocol User blind( note ) unblind( sign( blind( note ))) = sign( note )  Bank (mint)  sign( blind( note )) User ends up with a note signed by the bank • Note is not tied to user • Implemented as an electronic purse which holds arbitrary denominations .Book Entry System Variations Some systems (eg GlobeID) have the consumer (instead of the merchant) do the messaging Credit cards don’t handle small transactions very well.

Digicash (ctd) Using e-cash • Send note to merchant • Merchant redeems note at bank • Double spending is avoided by having the user ID revealed if the note is banked twice (ZKP) – The fielded system just keeps a record of already spent notes. which is easier Digicash (ctd) Problems • Banks don’t like it (anyone can be a bank) • Governments don’t like it • Not used much (awkward/fluctuating licensing requirements) – Licensed as if it were an RSA-style monopoly patent By the time they figure it out. collapsed . not so good business managers • Patents are currently in limbo after Digicash Inc. the patent will expire (2007) • Digicash principals are great cryptographers.

Making e-cash work Best e-cash business model is to earn seignorage by selling it • Bank earns interest on real cash corresponding to digital bits held by consumer • US Federal Reserve earns $20B/year in interest on outstanding dollar bills • Phone cards and gift vouchers are a small-scale example of this Consumers may demand interest on e-cash e-cash is useful for small transactions (micropayments) which other systems can’t handle • But what do you buy over the net for 10 cents? echecks Background for a US audience • Non-US automated payment processing is relatively sophisticated • Automatic payments (rent. wages) are handled via direct funds transfer • Funds are moved electronically from one account to another on the same day – Checks are used rarely – Electronic check proposals are met with bafflement . utilities.

echecks (ctd) Background for a non-US audience • US cheque and payment processing is very primitive • “Automatic payment” frequently means the payers bank writes a cheque and sends it to the payee • Payments are batched and held until a sufficient number have accumulated – The fact that funds leave the payers account on a given day doesn’t guarantee timely arrival in the payees account • Cheques are used extensively • Electronic cheques would be a significant advance on the current situation Electronic Cheque Design Requirements Cheques can involve • • • • One or more signers One or more endorsers Invoice(s) to be paid Deposit to account or cash Electronic version must be flexible enough to able to handle all of these .

endorsing. etc.e-cheque Design e-cheques are defined using FSML (Financial Services Markup Language) • FSML allows addition and deletion of document blocks. signing. Signatures are accompanied by bank-issued certificates • Tie the signers key to a bank account • Different account is used for e-cheques to protect standard cheque account against fraud e-cheque Design (ctd) Private key is held in smart card (electronic cheque book) • Card numbers each signature/cheque – Attempts to re-use cheques will be detected • Card keeps record of cheques signed – Provides some degree of protection against trojan horse software • Card provides some degree of non-repudiation • Use of software implementations rejected because of security concerns – “If hackers acquire signing keys and perpetuate fraud. payees confidence in the system would be destroyed” • Use of PDA’s as e-chequebooks was also considered . co-signing.

46 encapsulation e-cheque Processing (ctd) Cheque signature may also bind and invoice to avoid an attacker substituting a different invoice Mechanisms can be extended to provide certified cheques • Payers bank – Verifies details of cheque – Places hold on payers funds – Countersigns cheque e-cheque design is a good example of carefully designing a protocol to meet certain security requirements • Work around shortcomings in existing laws • Work around shortcomings in existing security technology .46 with FSML representation instead of cheque image • ANSI X9.37 cash letter contained in X9.e-cheque Processing Settlement is handled via existing standards • ANSI X9.

etc) </checkdata> End of elements logged <checkbook> ID of electronic chequebook <restrictions> Optional “duration”. etc <legalnotice> “Subject to standard cheque law” </check> End of cheque block e-cheque Format (ctd) Tag <signature> <blkname> <sigdata> <blockref> <hash alg=xxx> <nonce> <certissuer> <algorithm> </sigdata> <sig> </signature> Field Start tag of signature block Name of this block Start tag of signed data Name of next block Hash of next block Random string to make blocks unpredictable Optional identity of issuing certificate Hashing and signing algorithm used End of signed data Signature computed by electronic chequebook End of signature block . “deposit only”.e-cheque Format Tag <check> <checkdata> Field Start tag of cheque block Start tag of elements logged in electronic chequebook <checknum> Cheque number <dateissued> Date cheque was issued <datevalid> Date cheque is payable <amount> Amount of cheque (+optional currency) <payto> Payee (+optional bank. account.

STT (VISA/Microsoft) and SEPP (MasterCard/IBM) STT • • • • One component of a larger architecture Provision for strong encryption Completely new system More carefully thought out from a security standpoint SET (ctd) SEPP • • • • General architectural design rather than a precise specification Lowest-common-denominator crypto Fits in with existing infrastructure More politically and commercially astute .SET Secure Electronic Transactions Based on two earlier protocols.

for purchase tracking purposes • PI is cryptographically tied to the order instruction (OI) processed by the merchant • Clients digital signature protects the merchant from client repudiation Authorisation request includes the consumer PI and merchant equivalent of the PI • Acquirer can confirm that the cardholder and merchant agree on the purchase details .SET (ctd) Acquirer gateway is an Internet interface to the established credit card authorisation system and cardholder/merchant banks SET Features Card details are never disclosed to merchant • Encrypted purchase instruction (PI) can only be decrypted by the acquirer – In practice the acquirer usually reveals the card details to the merchant after approval.

SET Features (ctd) Capture can take place later (eg when the goods are shipped) • User can perform an inquiry transaction to check the status The whole SET protocol is vastly more complex than this SET Certification SET root CA and brand CA’s are rarely utilised and have very high security .

“certificate management” is easy • Acquirer gateways have long-term signature keys and shortterm encryption keys – Encryption keys can be revoked by letting them expire .SET Certification (ctd) SET includes a complete PKI using customised X.509 profile with SET-specific extensions SET Certification (ctd) Card-based infrastructure makes certificate management (relatively) easy • Users are identified by their cards • Certificates are revoked by cancelling the card • Because everything is done online.509 • Online certificate requests • Certificate distribution • Certificate revocation SET certificates are implemented as an X.

SET in Practice: Advantages SET will enable e-commerce. VISA interchange gateway currently has to handle 2000 pure DES-based transactions/second . eliminate world hunger.1 specification • 28-stage (!) transaction process – “The SET reference implementation will be available by mid 1996” – “SET 1. and close the ozone hole • SET prevents fraud in card not present transactions SET eliminates the need for a middleman (the banks love this) SET leverages the existing infrastructure SET in Practice: Problems SET is the most complex (published) crypto protocol ever designed • > 3000 lines of ASN.0 " " " mid 1998” • Interoperability across different implementations is a problem SET is awfully slow (6 RSA operations per transaction) • Great for crypto hardware accelerator manufacturers • For comparison.0 " " " mid 1997” – “SET 2.

you still can’t export the reference implementation SET requires • Custom wallet software on the cardholders PC • Custom merchant software • Special transaction processing software (and hardware) at the acquirer gateway.SET in Practice: Problems (ctd) Although SET was specifically designed for exportability. .

Electronic Commerce SET is the answer. but you have to phrase the question very carefully Electronic Payments An electronic payment system needs to be • • • • • Widely recognised Hard to fake Hold its value Convenient to use Anonymous/not anonymous Convenience is the most important point .

Cheques Merchant doesn’t know whether the cheque is valid until it’s cleared Cheques (ctd) Consumer can’t detect fraud until the statement arrives Cost of processing errors vastly outweighs the cost of normal actions .

banks with cheques don’t .Credit Cards Authentication is online Settlement is usually offline (batch processed at end of day) Credit Cards (ctd) Consumer can’t detect fraud until the statement arrives Cost of processing errors vastly outweighs the cost of normal actions Merchant carries the risk of fraud in card not present transactions Consumer liability is limited to $50 Far more merchant fraud than consumer fraud Credit card companies assume liability for their merchants.

Transactions on the Internet Transactions are fairly conventional card not present transactions and follow the precedent set by phone orders Online nature provides instant verification Biggest problems are authentication and confidentiality General Model of Internet Transactions Virtually all net payment systems consist of some variant of this Everyone wants to be the middleman .

many others Bearer certificate systems • Scrip (Millicent) • True digital cash (Digicash) . you can’t beat a credit card over SSL Business customers will buy to reduce current costs Payment Systems Book entry systems • • • • • • Credit cards over SSL Encrypted credit cards (Cybercash) Virtual credit cards (First Virtual) e-cheques (Netcash) Mondex/SET Many.Retail vs Business-to-business Commerce Retail commerce • Small dollar amounts • Stranger-to-stranger transactions Business-to-business commerce • Large dollar amounts • Based on trust relationships • Banks play a direct role — they guarantee the transaction – You can’t disintermediate the banks Business-to-business commerce is where the money is • For retail transactions.

Netcash e-cheques.cybercash. http://www.teleport.com . http://www.com/~netcash Cybercash Encrypted credit cards.

Book Entry System Variations Some systems (eg GlobeID) have the consumer (instead of the merchant) do the messaging Credit cards don’t handle small transactions very well. Some options are • Don’t handle micropayments at all • Middleman has to act as a bank • Use a betting protocol: 10 cent transaction = 1% chance of a $10 transaction Digicash Digicash issuing protocol User blind( note ) unblind( sign( blind( note ))) = sign( note )  Bank (mint)  sign( blind( note )) User ends up with a note signed by the bank • Note is not tied to user • Implemented as an electronic purse which holds arbitrary denominations .

the patent will expire (2007) • Digicash principals are great cryptographers. not so good business managers • Patents are currently in limbo after Digicash Inc. which is easier Digicash (ctd) Problems • Banks don’t like it (anyone can be a bank) • Governments don’t like it • Not used much (awkward/fluctuating licensing requirements) – Licensed as if it were an RSA-style monopoly patent By the time they figure it out.Digicash (ctd) Using e-cash • Send note to merchant • Merchant redeems note at bank • Double spending is avoided by having the user ID revealed if the note is banked twice (ZKP) – The fielded system just keeps a record of already spent notes. collapsed .

utilities. wages) are handled via direct funds transfer • Funds are moved electronically from one account to another on the same day – Checks are used rarely – Electronic check proposals are met with bafflement .Making e-cash work Best e-cash business model is to earn seignorage by selling it • Bank earns interest on real cash corresponding to digital bits held by consumer • US Federal Reserve earns $20B/year in interest on outstanding dollar bills • Phone cards and gift vouchers are a small-scale example of this Consumers may demand interest on e-cash e-cash is useful for small transactions (micropayments) which other systems can’t handle • But what do you buy over the net for 10 cents? echecks Background for a US audience • Non-US automated payment processing is relatively sophisticated • Automatic payments (rent.

echecks (ctd) Background for a non-US audience • US cheque and payment processing is very primitive • “Automatic payment” frequently means the payers bank writes a cheque and sends it to the payee • Payments are batched and held until a sufficient number have accumulated – The fact that funds leave the payers account on a given day doesn’t guarantee timely arrival in the payees account • Cheques are used extensively • Electronic cheques would be a significant advance on the current situation Electronic Cheque Design Requirements Cheques can involve • • • • One or more signers One or more endorsers Invoice(s) to be paid Deposit to account or cash Electronic version must be flexible enough to able to handle all of these .

payees confidence in the system would be destroyed” • Use of PDA’s as e-chequebooks was also considered .e-cheque Design e-cheques are defined using FSML (Financial Services Markup Language) • FSML allows addition and deletion of document blocks. endorsing. co-signing. Signatures are accompanied by bank-issued certificates • Tie the signers key to a bank account • Different account is used for e-cheques to protect standard cheque account against fraud e-cheque Design (ctd) Private key is held in smart card (electronic cheque book) • Card numbers each signature/cheque – Attempts to re-use cheques will be detected • Card keeps record of cheques signed – Provides some degree of protection against trojan horse software • Card provides some degree of non-repudiation • Use of software implementations rejected because of security concerns – “If hackers acquire signing keys and perpetuate fraud. etc. signing.

46 encapsulation e-cheque Processing (ctd) Cheque signature may also bind and invoice to avoid an attacker substituting a different invoice Mechanisms can be extended to provide certified cheques • Payers bank – Verifies details of cheque – Places hold on payers funds – Countersigns cheque e-cheque design is a good example of carefully designing a protocol to meet certain security requirements • Work around shortcomings in existing laws • Work around shortcomings in existing security technology .46 with FSML representation instead of cheque image • ANSI X9.37 cash letter contained in X9.e-cheque Processing Settlement is handled via existing standards • ANSI X9.

e-cheque Format Tag <check> <checkdata> Field Start tag of cheque block Start tag of elements logged in electronic chequebook <checknum> Cheque number <dateissued> Date cheque was issued <datevalid> Date cheque is payable <amount> Amount of cheque (+optional currency) <payto> Payee (+optional bank. account. “deposit only”. etc) </checkdata> End of elements logged <checkbook> ID of electronic chequebook <restrictions> Optional “duration”. etc <legalnotice> “Subject to standard cheque law” </check> End of cheque block e-cheque Format (ctd) Tag <signature> <blkname> <sigdata> <blockref> <hash alg=xxx> <nonce> <certissuer> <algorithm> </sigdata> <sig> </signature> Field Start tag of signature block Name of this block Start tag of signed data Name of next block Hash of next block Random string to make blocks unpredictable Optional identity of issuing certificate Hashing and signing algorithm used End of signed data Signature computed by electronic chequebook End of signature block .

STT (VISA/Microsoft) and SEPP (MasterCard/IBM) STT • • • • One component of a larger architecture Provision for strong encryption Completely new system More carefully thought out from a security standpoint SET (ctd) SEPP • • • • General architectural design rather than a precise specification Lowest-common-denominator crypto Fits in with existing infrastructure More politically and commercially astute .SET Secure Electronic Transactions Based on two earlier protocols.

for purchase tracking purposes • PI is cryptographically tied to the order instruction (OI) processed by the merchant • Clients digital signature protects the merchant from client repudiation Authorisation request includes the consumer PI and merchant equivalent of the PI • Acquirer can confirm that the cardholder and merchant agree on the purchase details .SET (ctd) Acquirer gateway is an Internet interface to the established credit card authorisation system and cardholder/merchant banks SET Features Card details are never disclosed to merchant • Encrypted purchase instruction (PI) can only be decrypted by the acquirer – In practice the acquirer usually reveals the card details to the merchant after approval.

SET Features (ctd) Capture can take place later (eg when the goods are shipped) • User can perform an inquiry transaction to check the status The whole SET protocol is vastly more complex than this SET Certification SET root CA and brand CA’s are rarely utilised and have very high security .

509 • Online certificate requests • Certificate distribution • Certificate revocation SET certificates are implemented as an X.SET Certification (ctd) SET includes a complete PKI using customised X.509 profile with SET-specific extensions SET Certification (ctd) Card-based infrastructure makes certificate management (relatively) easy • Users are identified by their cards • Certificates are revoked by cancelling the card • Because everything is done online. “certificate management” is easy • Acquirer gateways have long-term signature keys and shortterm encryption keys – Encryption keys can be revoked by letting them expire .

and close the ozone hole • SET prevents fraud in card not present transactions SET eliminates the need for a middleman (the banks love this) SET leverages the existing infrastructure SET in Practice: Problems SET is the most complex (published) crypto protocol ever designed • > 3000 lines of ASN.SET in Practice: Advantages SET will enable e-commerce. VISA interchange gateway currently has to handle 2000 pure DES-based transactions/second . eliminate world hunger.0 " " " mid 1998” • Interoperability across different implementations is a problem SET is awfully slow (6 RSA operations per transaction) • Great for crypto hardware accelerator manufacturers • For comparison.1 specification • 28-stage (!) transaction process – “The SET reference implementation will be available by mid 1996” – “SET 1.0 " " " mid 1997” – “SET 2.

.SET in Practice: Problems (ctd) Although SET was specifically designed for exportability. you still can’t export the reference implementation SET requires • Custom wallet software on the cardholders PC • Custom merchant software • Special transaction processing software (and hardware) at the acquirer gateway.

effectively unbreakable crypto is universally available (despite US government efforts) • Don’t attack the crypto.Practical Issues Of course my password is the same as my pet’s name My macaw’s name was Q47pY!3 and I change it every 90 days — Nick Simicich Practical Issues Strong. attack the infrastructure in which it’s used • " " " " implementation • " " " " users Many infrastructure/implementation details are treated as black boxes by developers • Storage protection/sanitisation • Long-term secret storage • Key generation .

a 99.99% security-bug-free program can be exploited by ensuring the 0.Why Security is Harder than it Looks All software has bugs Under normal usage conditions.99% bug-free program will rarely cause problems A 99. making it a UTCB • Consumers buy the product anyway (see above) .01% failure to 100% failure Why Security is Harder than it Looks (ctd) Customers have come to expect buggy software • Correctness is not a selling point • Expensive and time-consuming software validation and verification is hard to justify Solution: Confine security functionality into a small subset of functions. the trusted computing base (TCB) • In theory the TCB is small and relatively easy to analyse • In practice vendors end up stuffing everything into the TCB.01% instance is always encountered This converts the 0.

Tooltalk. mscreen. mountd. lha. catdoc. df. NIS+. klogd. host.4). ping. lpr. libDtSvc. passwd/yppasswd/nispasswd. rlogin again. Cisco IOS. mutt. xterm. wwwcount. sendmail yet again. the Yapp conferencing server. sendmail for Windows NT. permissions. eeprom. term. filter (part of elm-2. smbmount.83. mount. and rdist Buffer Overflows (ctd) Typical case: Long URL’s • Data at the end of the URL overwrites the program counter/return address • When the subroutines returns. suidperl. the IMail POP3 server for NT. pcnfs. Minicom.c. dslip. deliver.1. SuperProbe. login/scheme. Xaw library. xlock again. libX11. telnetd. ps. talkd. xlock yet again. sendmail. SLMail. an entire range of SGI programs. rlogin. iwsh. rsh. MSIE. host. login. libXt and further X11R6 libraries. junkbuster. Lotus Notes. dtaction. it jumps to the attackers code . dtterm. fbconfig. MSIE. eject. libX11. Cisco 7xx routers. the query CGI script. SerialPOP. bash. newgrp. rcp. imapd (again). rlogin. pine. Xserver. cidentd. elvis. lpd. gethostbyname(). mount/umount. elm. talkd. imapd. Netscape Mail. df. cxterm.Buffer Overflows In the last year or two these have appeared in splitvt. ipop3d. at again. multiple problems in the Windows95/NT NTFTP client. chkey. socks5. fdformat. Novell Groupwise. xterm. Netscape (all versions). getopt(). ordist. ffbconfig. compress. at. FreeBSD’s crt0. WebCam32. ps again. xlock. DCE secd. AutoSofts RTS inventory control system. unfsd. xdat. libauth. passwd. mutt again. dbadmin. termcap. lpr yet again. jidentd. sdtcm_convert. ps again. CSM Proxy. pset. nslookup. metamail. WebSite 1. lpd again. writesrv. Real Player. ufsrestore. the Linux dynamic linker. dig. MH-6. eject. cron. traceroute. lquerylv. Outlook Express. rpc. opengroup. libX11 again. bind. the NLS library. Samba server. rdist. tgetent(). zpop. mpg123. ttdbserver. bash. syslog. portmir. login. wm. eject. sendmail again. Xprt. modstat. getopt() again. statd. ospf_monitor. zgv.nisd. smbclient. libXt again. MSIE again. the Windows War and Serv-U FTP daemon. xscreensaver.

but • RAM can be swapped to disk at any moment – Users of one commercial product found multiple copies of their encryption password in the Windows swap file – “Suspend to disk” feature in laptops is particularly troublesome • Other processes may be able to read it from memory • Data can be recovered from RAM after power is removed .Fixing Overflow Problems More careful programming • Isolate security functionality into carefully-checked code Make the stack non-executable Compiler-based solutions • Build bounds checking into the code (very slow) • Build stack checking into the code (slight slowdown) • Rearrange stack variables (no slowdown) Storage Protection Sensitive data is routinely stored in RAM.

Protecting Memory Locking sensitive data into memory isn’t easy Unix: mlock() usable by superuser only Win16: No security Win95/98: VirtualLock() does nothing WinNT: VirtualLock() doesn’t work as advertised (data is still swapped) • Macintosh: HoldMemory() • • • • Scan memory for data: VirtualQueryEx() VirtualUnprotectEx() ReadProcessMemory() Protecting Memory (ctd) Create DIY swapfile using memory-mapped files • Memory is swapped to a known file rather than system swapfile • File is wiped after use Problems: • Truly erasing disk data is impossible • Data isn’t wiped on system crash/power loss .

WinNT) – Many Windows file-wipers are caught by this . leaving the target data intact • Disk cacheing will discard overwrites if the file is unlinked immediately afterwards (Win95/98.Protecting Memory (ctd) Force memory to remain in use at all times • Background thread touches memory periodically Allocate non-pageable memory • Requires a kernel driver • Mapping memory from kernel to user address space is difficult Storage Sanitisation Problems in erasing disk data • Defect management systems move/remap data. making it inaccesible through normal means • Journaling filesystems retain older data over long periods of time • Online compression schemes compress fixed overwrite patterns to nothing.

Recovering Data One or two passes can be easily recovered by “error cancelling” • • • • Read actual (digital) data Read raw analog signal Subtract expected signal due to data from actual analog signal Result is previous (overwritten) data US government standard (DoD 5200. all 1’s. alternating 0’s and 1’s) is particularly bad Design overwrite patterns to match HD encoding methods Advanced Data Recovery Ferrofluid + optical microscopes • Defeated by modern high-density storage systems Scanning probe microscopes overcame this problem • Oscillating probe is scanned across the surface of the object • Change in probe movement measured by laser interferometer Can be built for a few thousand dollars Commercial ones specifically set up for disk platter analysis are available .28) with fixed patterns (all 0’s.

but can do far more • Erase bands (partially-overwritten data at the edges) retain previous track images • Overwriting one set of data with another causes track width modulation • Erased/degaussed drives can often still be read with an MFM – Modern high-density media can’t be effectively degaussed with commercial tools . Read magnetic force (adjusted for topography) Advanced Data Recovery (ctd) MFM’s can be used as expensive read channels. Read disk topography 2.Advanced Data Recovery (ctd) Magnetic force microscope (MFM) 1.

destroy the media – Where does your returned-under-warranty drive end up? – For file servers.Advanced Data Recovery (ctd) Recommendations • Use the smallest. always destroy the media (there’s always something sensitive on there) Recovering Memory Data Electrical stress causes ion migration in DRAM cells Data can be recovered using special (undocumented) test modes which measure changes in cell thresholds • At room temperature. business data. decay can take minutes or hours • At cryogenic temperatures. highest-density drives possible • If data is sensitive. decay can take weeks? months? A quick overwrite doesn’t help much Solution is to only store data for short periods • Relocate data periodically • Toggle bits in memory .

tv_sec ^ getpid() ^ gethostid() ^ counter++ ). key = MD5( seed++ ).tv_usec ^ time.tv_usec ). key = random(). b ). . nonce = MD5( seed++ ). b = mixbits( getpid() + time. seed = MD5( a. but isn’t available on a standalone server Many implementations leave it to application developers (who invariably get it wrong) Bad RNG’s Netscape a = mixbits( time.Random Number Generation Key generation requires large quantities of unpredictable random numbers • Very difficult to produce on a PC • Most behaviour is predictable • User input can be unpredictable. Kerberos V4 srandom( time.tv_sec + ( getppid() << 12 ).

Sesame. Lavarand Physical source + SG100 postprocessing Multi-source polling SKIP.x. PGP 5. Types of Generator Generator consists of two parts • Polling mechanism to gather random data • Pseudo-random number generator (PRNG) to “stretch” the output Physical source Various hardware generators. BSAFE Secret fixed value + ANSI X9. Kerberos V4.x.17 PRNG Known value + PRNG Netscape. /dev/random Secret nonce + PRNG Applied Cryptography. cryptlib Single-source polling PGP 2. and many more . Hotbits (radioactive decay).Bad RNG’s (ctd) MIT_MAGIC_COOKIE key = rand() % 256. SESAME key = rand().

17 Relies on strength of triple DES encryption and supplied encryption key .Example: Unix /dev/random Example: ANSI X9.

CD.Randomness Sources • • • • • • Process and thread information Mouse and keyboard activity Memory and disk usage statistics System timers Network statistics GUI-related information Run periodic background polls of sources Try and estimate the randomness available. one CD) produces half the randomness of maximum PC hardware (multiple HD’s. if insufficient • Perform further polling • Inform the user Effectiveness of the Randomness Source Effects of configuation • Minimal PC hardware (one HD. SCSI HD and CD) Effects of system load and usage • Statistics change little over time on an unloaded machine • A reboot drastically affects the system state – Reboot the machine after generating a high-value key . network card.

but first publicised by van Eck in 1985 • Provided details on remote viewing of computer monitors • Required about $15 worth of parts (for sync recovery) • The spooks were not happy TEMPEST Principles Fast-rise pulses lead to harmonics radiated from semiconductor junctions • Used to detect bugs – Flood the room with microwaves – Watch for radiated responses Anything which carries a current acts as an antenna TEMPEST monitoring gear receives and interprets this information .TEMPEST Sometimes claimed to stand for Transient Electromagnetic Pulse Emission Standard Known since the 1950’s.

since sync frequencies are too low to be radiated • Individual monitors can be picked out even when other similar monitors are in use • Jamming is often ineffective for protection – Eavesdroppers can still zero in on a particular monitor TEMPEST Sources (ctd) Keyboard • Some keyboards produce distinct RF signatures for each key pressed • Active monitoring – Beam RF energy at the keyboard cable – Reflected signal is modulated by abscence/presence of electrical current Ethernet • UTP can be intercepted over some distance . little to the front and back • Requires external horizontal/vertical sync insertion.TEMPEST Sources Computer monitor/laptop screen • Generally radiates huge amounts of signal (range of hundreds of metres) • Most signal is radiated to the sides.

phone lines.TEMPEST Sources (ctd) Printer and serial cables Leakage into power lines Coupling into power lines. phone lines Shielded cables Ferrite toroids around cables to attenuate surface waves Radio hams have information on safely operating computers near sensitive comms gear Use a portable radio as a simple radiation tester . metal pipes • Further radiation from there Surface waves on coax lines TEMPEST Protection Extremely difficult to protect against Stopping it entirely • Extreme amounts of shielding on all equipment • Run the equipment inside a Faraday cage Stopping it partially • • • • • FCC Class B computers and equipment RF filters on power lines.

Snake Oil Cryptography Named after magic cure-all elixirs sold by travelling medicine salesmen Many crypto products are sold using similar techniques • The crypto has similar effectiveness • This is so common that there’s a special term. “snake oil crypto”. neural nets. I know what I'm doing” – They usually don’t • Most security through obscurity schemes are eventually broken – Once someone finds out what your secret security system is. and chaos theory • See “security through obscurity” . to describe it Snake Oil Warning Signs Security through obscurity • “Trust me. it’s no longer a secret and no longer secure – It’s very hard to keep a secret on the net Proprietary algorithms and revolutionary breakthroughs • “I know more about algorithm design than the entire world’s cryptographers” • Common snake oil warning signs are use of cellular automata. genetic algorithms.

it’s broken . everyone else uses block ciphers – Keys are generally symmetric and centrally managed. no matter how bad. and therefore not unbreakable “Military-grade crypto” • Completely meaningless term (cf “military-grade spreadsheet”) – Military tends to use hardware. everyone else uses distributed PKC keys • Products should therefore be advertised as “nothing like military-grade crypto” Snake Oil Warning Signs (ctd) Technobabble • Use of terms unknown to anyone else in the industry Used by xyz • Every product. will gain at least one bigname reference customer Exportable from the US • Except for special-purpose cases (eg SGC). the US government will not allow the export of anything which provides real security • If it’s freely exportable. civilians use software – Prefer shift-register based stream ciphers.Snake Oil Warning Signs (ctd) Unbreakability • Usually claimed by equating the product to a one-time-pad • Product isn’t a one-time-pad.

using a proprietary one-time-pad algorithm.Snake Oil Warning Signs (ctd) Security challenges • Generally set up to make it impossible to succeed • These things always get the media’s attention. especially if the reward is huge (chance of press coverage = 20% per zero after the first digit) Snake Oil Warning Signs (ctd) Would you buy this product? • “Our unbreakable military-grade bi-gaussian cryptography. they’ll probably sell it as snake oil . be careful how your marketing people handle it – If left to their own devices. has recently been adopted by a Fortune 500 customer and is available for use inside and outside the US” Badly marketed good crypto is indistinguishable from snake oil • If you’re selling a crypto product.

“keeps files and data on your PC as safe as if they were under lock and key” more • • • • Snake Oil in the Media (ctd) continued • The Windows95 Application List: “an excellent application for protecting your personal files” • RocketDownload: Four smilies • “Simply the Best” site award One major publication once rated a collection of encryption programs by how good the user interface looked . “a must have for anyone sharing a computer with files they want to keep private” • PC Format: “Unbeatable and excellent file encryption” • TUCOWS: Rated 4 cows • Ziff-Davis Interactive: 5 stars.Snake Oil in the Media Magazine reviews are a poor gauge of software security WinXFiles (trivially broken file encryption) PC Answers: Listed in “10 proven security programs” Windows News: Listed in “75 best Windows utilities” FileMine: Rated as a Featured Jewel Shareware Junkies: 5 stars.

. a system of pointers is being created.000 people tried to break our product” – 55.000 visited their web page • “Working on standardising VME with the different standards committees” Snake Oil Case Study (ctd) Challenged large companies to break their unbreakable crypto • Enumerate each company in the PR to ensure that their name is associated with large..Snake Oil Case Study Meganet Virtual Matrix Encryption • “A new kind of encryption and a new algorithm. different from any existing method” • “By copying the data to a random built-in Virtual Matrix.” • “The worlds first and only unbreakable crypto” • “We challenged the top 250 companies in the US to break our products. None succeeded” – They don’t even know Meganet exists • “55. . publicly held stocks Used accounts at organisations like BusinessWire and PRNewswire to inject bogus press releases into newswires • Run anything at $500 for 400 words • Claimed IBM was so impressed with their product that they were recommending it for the AES – IBM had never heard of them .

Snake Oil (ctd) Big-name companies sell snake oil too Tools exist to recover passwords for • Adobe Acrobat/PDF • ACE archives • ACIUS 4th Dimension • Arj archives • Clarion • Claris Filemaker Pro • CompuServe WinCim • dBASE • Diet compressed files • Eudora • ICQ • Lotus 1-2-3 Continues Snake Oil (ctd) Continued • Lotus Ami-Pro • Lotus Organiser • Lotus Symphony • Lotus WordPro • LZEXE compressed files • MS Access • MS Backup • MS Excel • MS Mail • MS Money • MS Outlook • MS Project • MS Scheduler Continues .

Snake Oil (ctd) Continued • MS Word • MYOB • Norton Secret Stuff • Paradox • Pegasus Mail • Pklite compressed files • Pkzip archives • Q&A Database • Quattro Pro • QuickBooks • Quicken • Stacker • Symantec Act Continues Snake Oil (ctd) Continued • Trumpet Winsock • VBA projects • WinCrypt • Windows 3. many more .. and many.1/95/98 passwords • Windows Dial-up Networking (DUN) • Windows NT/2000 passwords • WinXFiles • WordPerfect • WS FTP ..

there’s no way to financially measure the effectiveness of a security system Selling Security to Management Regulatory issues • Liability for negligence (poor security/weak crypto) • Shareholders could sue the company if share price drops due to security breach • US companies spend more on security due to litigation threats Privacy/data protection requirements Media stories of hacker/criminal attacks on systems The best security customers • Have just been publicly embarrassed • Are facing an audit . insurance firms should tie premiums to security measures • Unfortunately.Selling Security Security doesn’t sell well to management Many security systems are designed to show due diligence or to shift blame • Crypto/security evidence from these systems is very easy to challenge in court You get no credit if it works. and all the blame if it doesn’t To ensure good security.

Miscellaneous Topics Buy a rifle. photocopying. snack food) . and wait for the revolution Smart Cards Invented in the early 1970’s Technology became viable in early 1980’s Major use is prepaid telephone cards (hundreds of millions) • Use a one-way (down) counter to store card balance Other uses • Student ID/library cards • Patient data • Micropayments (bus fares. encrypt your data.

000 write/erase cycles • 10ms to write a cell or group of cells Cost: $5 Microprocessor Cards ROM/RAM contains card operating system and working storage EEPROM used for data storage .Memory Cards Usually based on I2C (serial memory) bus Typical capacity: 256 bytes EEPROM capabilities • Nonvolatile storage • 10.

contact layout. which defines • Card size. electrical characteristics • I/O protocols – Byte-based – Block-based • File structures Terminology alert: Vendor literature often misuses standard terms • “Digital signature” = simple checksum or MAC • “Certificate” = data + “digital signature” .Microprocessor Cards (ctd) Typical specifications • • • • 8-bit CPU 16K ROM 256 bytes RAM 4K EEPROM Size ratio of memory cells: RAM = 4 EEPROM size = 16 ROM size Cost: $5-50 (with crypto accelerator) Smart Card Technology Based on ISO 7816 standard.

File Structures Files addressed by 16-bit file ID (FID) • FID is often broken into DF:EF parts (MF is always 0x3F00) Files are generally fixed-length and fixed-format File Types Transparent • Binary blob Linear fixed • n  fixed-length records Linear variable • n records of fixed (but different) lengths Cyclic • Linear fixed. oldest record gets overwritten Execute • Special case of transparent file .

limited number of write cycles) which are supported by card attributes • WORM. update is a genuine write • ERASE BINARY • READ/WRITE/UPDATE RECORD • APPEND RECORD • INCREASE/DECREASE – Changes cyclic file position . only written once • Multiple write. ensures atomic file writes – Power can be removed at any point – Requires complex buffering and state handling Card Commands Typical commands are • CREATE/SELECT/DELETE FILE • READ/WRITE/UPDATE BINARY – Write can only change bits from 1 to 0. uses redundant cells to recover when some cells die • Error detection/correction capabilities for high-value data • Error recovery.File Attributes EEPROM has special requirements (slow write.

Card Commands (ctd) Access control • • • • • Based on PIN of chip holder verification (CHV) VERIFY CHV CHANGE CHV UNBLOCK CHV ENABLE/DISABLE CHV Authentication • Simple challenge/response authentication protocol • INTERNAL AUTHENTICATE – Authenticate card to terminal • EXTERNAL AUTHENTICATE – Authenticate terminal to card Card Commands (ctd) Encryption: Various functions. typically • ENCRYPT/DECRYPT • SIGN DATA/VERIFY SIGNATURE Electronic purse instructions • INITIALISE/CREDIT/DEBIT Application-specific instructions • RUN GSM ALGORITHM .

payment types and parameters.prEN 1546 Inter-sector electronic purse (IEP) standard. CONVERT IEP CURRENCY. and other details to implementors • Specifies the file layout and data elements for the IEP • Defines commands INITIALISE IEP. DEBIT IEP. CREDIT IEP. but leaves algorithms. 1995 Both customer and merchant use smart-card based electronic purses to handle payment transactions prEN 1546 (ctd) Defines the overall framework in some detail. and UPDATE IEP PARAMETER • Specifies exact payment routines in a BASIC-like pseudolanguage • All messages are “signed” (typically with a 4-byte DES MAC) • Handles everything but purse-to-purse transactions Includes many variants including a cut-down version for phonecards and extra acknowledgements for transactions .

Credit IEP Transaction IEP INITIALISE bank for load (amount and currency) Verify details Sign( DEBIT account ) Verify details Update card state Sign( Load acknowledgement )    Bank Verify currency and balance  INITIALISE IEP for load Verify details Debit account  Sign( CREDIT IEP ) Verify acknowledgement Credit Merchant Transaction IEP Merchant  INITIALISE IEP for purchase Sign( INITIALISE merchant  for purchase) Verify details Update card state Sign( CREDIT Merchant )  Verify details  Sign( DEBIT IEP) Verify details Record transaction for transmission to bank  Sign( Purchase acknowledgement) .

custom handling is required for each card type .TeleQuick Austrian CEN 1546 Quick electronic purse adapted for online use • Merchant  customer = Internet • Merchant  bank = X.25 All communications uses strong SSL encryption and server certificates Conceived as a standard Quick transaction with terminals a long way apart • Transaction rollback in case of communications faults • Virtual ATM must handle multiple simultaneous transactions – Handled via host security modules (HSM’s) • Windows PC is an insecure platform – Move functionality into read (LCD. crypt module) Working with Cards ISO 7816 provides only a standardised command set. implementation details are left to vendors • Everyone does it differently Standardised API’s are slow to appear PKCS #11 (crypto token interface) is the most common API • Functionality is constantly changing to handle different card/vendor features • Vendors typically only implement the portions which correspond to their products • For any nontrivial application. keypad.

or reinstalling/updating drivers. is a recipe for disaster – Drivers need to be installed in exactly the right order – PC operations may be affected (eg other peripherals stop working. known key “for security reasons” • General Information Systems OSCAR: XOR’s the DES key with a random number “for security reasons” • Gemplus GPK: Restricts keys to 40 bits • • • • . system functions are disabled) – Drivers/readers may cease to function entirely • USB readers seem to be the safest bet Working with Cards (ctd) Even finding basic DES encryption which works is tricky Schlumberger Cryptoflex: Doesn’t make DES user-accessible Schlumberger Multiflex: Returns only 6 of 8 encrypted bytes IBM MFC: Encrypts a random number Maosco MULTOS: Uses a fixed.Working with Cards (ctd) The Smart Card Problem • No cards • No readers • No software Installation of readers and cards is too problematic • Keyboard and mouse (or all of Windows) may stop working • Installing more than one reader.

certificates.PKCS #11 Object-oriented interface to any type of crypto token • • • • • • Smart card Crypto hardware accelerator Fortezza card USB-based token Handheld PC (eg PalmPilot) Software implementation Programming interface is (in theory) completely independent of the underlying token type PKCS #11 (ctd) Token provides various services to the caller • Store public/private keys. secret keys. authentication values. generate random data • Find object in token . generic data • Encrypt/decrypt • Sign/signature check • Wrap/unwrap key • Generate key.

PKCS #11 (ctd) Services can be restricted until the user has logged on using a PIN/password PKCS #11 Token Objects Token objects are structured in a hierarchical manner Object Key Public Key RSA Public Key DSA Public Key DH Public Key KEA Public Key Private Key RSA Private Key DSA Private Key DH Private Key KEA Private Key Secret Key DES Key 3DES Key RC2/RC4/RC5 Key Skipjack Key Certificate X.509 Certificate Data .

PKCS #11 trades some utility in exchange for flexibility . eg RSA private key has: • Object attributes CKA_CLASS = CKO_PRIVATE_KEY CKA_TOKEN = TRUE CKA_PRIVATE = TRUE CKA_MODIFIABLE = FALSE CKA_LABEL = “My private key” (persistent object) (needs login to use) (can’t be altered) (object ID for humans) • Key attributes CKA_KEY_TYPE = CKK_RSA CKA_ID = 2A170D462582F309 CKA_LOCAL = TRUE (object ID for computers) (key generated on token) PKCS #11 Token Objects (ctd) • Private Key attributes CKA_SENSITIVE = TRUE CKA_EXTRACTABLE = FALSE CKA_DECRYPT = TRUE CKA_SIGN = TRUE CKA_UNWRAP = TRUE (attributes can’t be revealed outside token) (can’t be exported from token) (can be used to decrypt data) (can be used to sign data) (can be used to unwrap encryption keys) • RSA Private Key attributes CKA_MODULUS = … CKA_PUBLIC_EXPONENT = … CKA_PRIVATE_EXPONENT = … CKA_PRIME_1 = … CKA_PRIME_2 = … CKA_EXPONENT_1 = … CKA_EXPONENT_2 = … Like a rubber screwdriver or styrofoam broadsword.PKCS #11 Token Objects (ctd) Each object has a collection of attributes.

memory management. most class libraries. and all security (via the bytecode verifier)) stripped out – Can run up to 200 times slower than card native code Provides the ability to mention both “Java” and “smart cards” in the same sales literature JavaCard (ctd) Card contains multiple applets • External client sends select command to card • Card selects applet and invokes its select method • Further commands sent by the client are forwarded to the applets process method • Applet is shut down via deselect method when a new select command is received Applet can access packages and services from other applets • How to do this securely is still under debate .JavaCard Standard smart card with an interpreter for a Java-like language in ROM • Card runs Java with most features (multiple data types.

object-oriented framework for smart card developers • Class contains a blueprint for an object • Object is an instance of a class OCF (ctd) class SmartCard CardID – Information identifying the card CardServiceFactory CardService: PurseCardService CardService: FileSystemCardService CardService: … CardServiceRegistry – Looks up requested CardService in CardServiceFactory – Instantiates a new CardService object for the caller CardServiceScheduler – Communicates with the card terminal – Coordinates access to card services .OCF Open Card Framework.

CardFileOutputStream class Terminal Slot – Information on reader slot + optional display. CardFileInputStream. card insertion check) • Integrated circuit card (ICC) resource manager – Controls all IFD’s attached to the system . … CardFilePath. LINEAR FIXED. keyboard CardTerminalFactory CardTerminal CardTerminalRegistry – As CardServiceRegistry PC/SC Interoperability Specification for ICC’s and Personal Computer Systems • Microsoft’s attempt to kill PKCS #11 (c. PCT vs SSL) • Goes a long way towards solving the Smart Card Problem PC/SC spec defines • Physical and electrical characteristics as ISO 7816 • Interface device (IFD) handler – Common software interface for card readers – Sets out minimal IFD requirements (command handling.f.OCF (ctd) class CardFile Attributes – TRANSPARENT.

PC/SC (ctd) PC/SC spec (ctd) • ICC service provider (ICCSP) – Maintains context of a card session • Crypto service provider (CSP) – Optional manager for crypto functionality – Separated out for export control purposes Getting it all to work properly was a remarkable achievement PC/SC (ctd) Provided as part of newer Windows releases • Simon Bill says smartcards .

5 MHz clock (slow 8-bit CPU) • No on-board battery (power analysis attacks) • Limited chip size (5mm2) and thickness due to packaging constraints Other crypto token form factors (USB token. Datakey) avoid these problems . card can’t do anything else while communicating • 3. PCMCIA card.PKCS #11 vs OCF vs PC/SC Language OS PKCS #11 Any OCF Java PC/SC Any Abstraction Level Any High JVM Low Windows Low (ICCSP) High (CSP) PKCS #11: Powerful but complex to implement  slow to appear OCF: By Java programmers for Java programmers PC/SC: Any platform you want as long as it’s Windows (limited availability under Linux) Smart Card Limitations Typical cards have the following limits • 9600bps only (~1K/sec communication rate) – A single public-key operation can take seconds just to communicate the data – Many card CPU’s are also used for I/O. iButton.

32K ROM. and data storage to crypto iButton • 8051 processor. 6K NVRAM • 1024-bit crypto accelerator • Real-time clock iButton Security iButton package allows for much better security measures than smart cards • Various triggers erase memory if tampering is detected • Active face of chip is metallurgically bonded to base of can Energy reservoir capacitor is used to zeroise memory Timing crystal drives on-board clock .Dallas iButton Avoids most smart card problems by changing the packaging Device is contained in 165mm microcan • Stainless steel case is much stronger than smart card • Case contains built-in battery and clock • I/O doesn’t tie up a serial port – $10 iButton interface is cheaper than $50 card reader Capabilities range from simple serial-number ID. real-time clock.

monetary value.iButton Security (ctd) Zeroisation can be triggered by • • • • • Opening the case Disconnecting the battery Temperatures below -20º C or above 70º C Excessive voltage levels Attempts to penetrate the case to get to the chip – Chip contains screen to prevent microprobing iButton Programming The device recognises two roles • Crypto officer initialises the device – Create transaction group(s) – Set up information (keys. etc) – Set initial user PIN – Lock transaction group(s) • User utilises it after initialisation by crypto officer Device contains one default group (Dallas Primary Feature Set) initialised at manufacture • Allows crypto officer to initialise the device • Allows user to verify that crypto officer hasn’t altered certain initial options .

used to detect trojan signing software) • Device serial number Signing process • User hashes data with MD5. SHA-1.iButton Programming (ctd) Dallas Primary contains default private key generated by device at manufacture • Corresponding public key is certified by the manufacturer • Guarantees to a third party that a given initial key belongs to a given iButton • Users can generate further keys as required iButton Special Features Device provides enhanced signature capabilities using onboard resources • Signing time • Transaction counter (incremented for each signature. and timestamp • iButton signs hash using private key • User retrieves serial number. transaction counter. … • iButton hashes user-supplied hash with device serial number. RIPEMD-160. timestamp. transaction counter. and signature from iButton .

~1m. transport applications • Vicinity. ISO 14443 – Typical use: MIFARE. ISO 7816 • Close-coupled. PICC • Reader = Proximity Coupling Device. PCD Contactless Cards (ctd) Contactless card issues • Power and communications link is unstable • Background noise problems • Low power levels available – Boosting power increases RFI caused by carrier sidebands – Maximum range determined by level at which RFI still complies with emission laws • Transaction must be rapid (100-200ms) – Move as many people through as few turnstiles as possible . 0-2mm. 0-10cm. ISO 10536 – Abandoned in favour of proximity cards • Proximity. ISO 15693 – Typical use: RFID Terminology and specs mirror ISO 7816 • Card = Proximity Integrated Circuit Card.Contactless Cards Several levels of contactless cards • Contact.

Contactless Card Communications Power and data transmitted at 13.56MHz/128) Card communicates with reader using load modulation • Switches a load resistor in and out of circuit • Reader detects changes in load Contactless Card Communications (ctd) Load modulation types • Type A. complex and inefficient — included for political reasons . simple and efficient • Type B.56 MHz • Card coil requires only a few turns • Coil can be printed circuit or a standard wire coil • Card and reader communicate at 106 Kbps (13.

card measures distance between pauses • Detecting errors like dropped bits is very simple Initialisation and Anticollision Handling Card initialisation • Reader actives all cards using wakeup frame – Wakeup frame has special format to distinguish it from normal frames • Extraneous cards weeded out using collision detection .Contactless Card Communications (ctd) Reader communicates with card using ASK • 100% amplitude shift keying = turn carrier on and off • CMOS circuits in card consume no power when not switched Encoding uses a modified Miller code • Carrier pauses at different positions • To decode.

FSK for VICC  VCD – Communication rate 6. high volume.6 Kbps – Variations on modulation.Vicinity Cards Extend proximity card ideas • PCD  VCD (Vicinity card device) • PICC  VICC (Vicinity integrated circuit card) Vicinity card requirements • Low-cost. simple cards More commonly use type B modulation • Less RFI allows operation over longer ranges • Use PPM (pulse position modulation) for VCD  VICC. and baud rate for different applications (speed vs distance vs noise immunity vs emission levels) Attacks on Smart Cards Use doctored terminal/card reader • Reuse and/or replay authentication to card • Display $x transaction but debit $y • Debit account multiple times Protocol attacks • Card security protocols are often simple and not terribly secure Fool CPU into reading from external instead of internal ROM Manipulating supply voltages can affect security mechanisms • Picbuster • Clock/power glitches can affect execution of instructions . coding. long range.

Attacks on Smart Cards (ctd) Erasing an EEPROM cell requires a high voltage (12 vs 5V) charge • Don’t provide the power to erase cells • Most cards now generate the voltage internally – Destroy the (usually large) on-chip voltage generator to ensure the memory is never erased Physical Attacks Erase onboard EPROM with UV spot beam Remove chip from encapsulation with nitric acid • Use microprobing to access internal circuit sections • Use electron-beam tester to read signals from the operational circuit Example: PIN recovery with an e-beam tester .

sealed environment contains very little unpredictable state Possible attacks • Cycle the RNG until the EEPROM locks up • Drop the operating voltage to upset analogue-circuit RNG’s • French government attack: Force manufacturers to disable key generation – This was probably a blessing in disguise. since externally generated keys may be much safer to use .Physical Attacks (ctd) Modify the circuit using a focused ion beam (FIB) workstation • Disable/bypass security circuitry (Mondex) • Disconnect all but EEPROM and CPU read circuitry Attacking the Random Number Generator Generating good random data (for encryption keys) on a card is exceedingly difficult • Self-contained.

modem DSP. software building blocks) .Timing/Power Analysis Crypto operations in cards • Take variable amounts of time depending on key and data bits • Use variable amounts of power depending on key and data bits – Transistors are voltage-controlled switches which consume power and produce electromagnetic radiation – Power analysis can provide a picture of DES or RSA en/decrypt operations – Recovers 512-bit RSA key at ~3 bits/min on a PPro 200 Differential power analysis is even more powerful • Many card challenge/response protocols are DES-based  apply many challenge/response operations and observe power signature Voice Encryption Built from three components Hardware-based • DSP with GSM or CELP speech compression • DSP modem Software-based • GSM or CELP in software • External modem or TCP/IP network connection Mostly built from off-the-shelf parts (GSM DSP.

terminals/users cleared at a single level • “Make it simple enough that even a general can understand it” • Attempts to apply it to other areas (eg networks) via increasingly tortuous “interpretations” Applying the Orange Book Maximum sensitivity Rmax Unclassified (U) Unclassified but sensitive (N) Confidential (C) Secret (S) Top Secret (TS) 0 1 2 3 5 Minimum user clearance Uncleared (U) Uncleared.TCSEC/Orange Book Trusted Computer Security Evaluation Criteria • Based on 10-15 years of security research • Usage model: multiuser mainframes. allowed access to sensitive information (N) Confidential (C) Secret (S) Top Secret (TS)/Background Investigation Top Secret (TS)/Special Background Investigation Rmin 0 1 2 3 4 5 Risk Index = Rmin – Rmax .

multilevel Limited access. not all users cleared for all levels . compartmented. multilevel Multilevel Multilevel Orange Book class None C2 B1 B2 B3 A1 ? Applying the Orange Book (ctd) Operating modes Dedicated System high Limited access Controlled System exclusively used for one classification Entire system operated at and all users cleared at highest sensitivity level of information All users not fully cleared or authorised access to all data Limited multilevel Compartmented At least one compartment requiring special access to which not all users have been cleared. controlled. compartmented.Applying the Orange Book (ctd) Risk index 0 0 1 2 3 4 5 Operating Mode Dedicated System high Limited access. controlled. but all users cleared to highest level Multilevel Two or more classification levels. multilevel Controlled.

Blowfish (smaller manufacturers. IDEA.fourmilab.html • Typical software implementation • Uses standard software components • Portable across several operating systems . http://www.ch/netfone/windows/ speak_freely. software) Password/PIN authentication Typical Voice Encryption System (ctd) Communications • Built-in modem (hardware) • Internet communications (software) Speak Freely.Typical Voice Encryption System Speech compression • GSM compression (high-bandwidth) • CELP compression (low-bandwidth) Security • • • • DH key exchange DES (larger manufacturers) 3DES.

Problems Latency issues (dropped packets) Authentication/MITM attacks No standardisation GSM GSM subscriber identity module (SIM) contains • International Mobile Subscriber Identity (IMSI) • Subscriber identification key Ki Used for authentication and encryption via simple challenge/response protocol • A3 and A8 algorithms provide authentication (usually combined as COMP128) • A5 provides encryption .

GSM (ctd) Authentication is simple challenge/response using A3 and IMSI/Ki GSM Security A3 used to generate response A8 used to generate A5 key .

allows IMSI and Ki to be extracted – Direct access to SIM (cellphone cloning) – Over-the-air queries to phone • Some cards were later modified to limit the number of COMP128 queries • A5 was deliberately weakened by zeroing 10 key bits – Even where providers don’t use COMP128. Base station transmits 128-bit challenge RAND 2.GSM Security (ctd) 1. RAND and Ki are combined via A8 to give a 64-bit A5 key 4. 114-bit frames are encrypted using the key and frame number as input to A5 GSM Security (ctd) GSM security was broken in April 1998 • COMP128 is weak. all shorten the key • Claimed GSM fraud detection system doesn’t seem to exist • Affects 80 million GSM phones . Mobile unit returns 32-bit signed response SRES via A3 3.

08 Rev 3.2 (BSSM) HaNDover REQuest (HOREQ) -------0 Discrimination bit D BSSMAP 0000000.1 ******** Encryption Key C9 7F 45 7E 29 8E 08 00 Classmark Information Type 2 GSM Security (ctd) Many countries were sold a weakened A5 called A5/2 • A5 security: Breakable in real time with 240 precomputations • A5/2 security: None (5 clock cycles to break) • Another attack is to bypass GSM entirely and attack the base station or land lines/microwave links GSM security was compromised at every level • Deliberately weakened key generation • Broken authentiction – GSM MoU knew of this nearly a decade ago but didn’t inform its members • A5/1 was known to be weak.Filler 00101011 Message Length 43 00010000 Message Type 0x10 Channel Type 00001011 IE Name Channel type 00000011 IE Length 3 00000001 Speech/Data Indicator Speech 00001000 Channel Rate/Type Full rate TCH channel Bm 00000001 Speech encoding algorithm GSM speech algorithm Encryption Information 00001010 IE Name Encryption information 00001001 IE Length 9 00000010 Algorithm ID GSM user data encryption V.GSM Security (ctd) Key weakening was confirmed by logs from GSM base stations BSSMAP GSM 08. A5/2 was deliberately designed to be weak GSM represents well-designed multiple-redundant compromise .9.

GSM Security (ctd) Most other cellphone security systems have been broken too • Secret design process with no public scrutiny or external review • Government interference to ensure poor security Traffic Analysis Monitors presence of communications and source/destination • Most common is analysis of web server logs • Search engines reveal information on popularity of pages • The mere presence of communications can reveal information .

Simple Anonymiser Proxy HTTP version at http://www.com Fairly easy to defeat: Mixes Encrypted messages sent over user-selected route through a network • Packet = A( B( C( D( E( data ))))) • Each server peels off a layer and forwards the data Servers can only see one hop Sender and receiver can’t be (easily) linked .anonymizer.

Attacks on Mixes Incoming messages result in outgoing messages • Reorder messages • Delay messages Message sizes change in a predictable manner Replay message (spam attack) • Many identical messages will emerge at some point Onion Routing Message routing using mixes.nrl. http://www.navy.mil/ITD/5540/ projects/onion-routing Routers have permanent socket connections Data is sent over short-term connections tunnelled over permanent connections • • • • • • 5-layer onions 48-byte datagrams CREATE/DESTROY for connection control DATA/PADDING to move datagrams Limited form of datagram reordering Onions are padded to compensate for removed layers .itd.

Mixmaster Uses message ID’s to stop replay attacks Message sizes never change • ‘Used’ headers are moved to the end. remaining headers are moved up one • Payload is padded to a fixed size • Large payloads are broken up into multiple messages • All parts of the message are encrypted Encryption is 1024 bit RSA with triple DES Message has 20 headers of 512 bytes and a 10K body Crowds Mixes have two main problems • Routers are a vulnerable attack point • Requires static routing Router vulnerability solved via jondo (anonymous persona) Messages are forwarded to a random jondo • Can’t tell whether a message originates at a given jondo • Message and reply follow the same path .

spamming • User connects to LPWA using email address and password • When web site asks for identification information. user types \u (user name). \@ (email address) • Proxy translates these to per-site pseudonymous personas Email forwarder forwards mail to users real email address • Spam sources can be blocked on a per-persona basis .LPWA Lucent Personalised Web Assistant • Provides access to web sites via LPWA proxy • Automatically generates per-site pseudonymous personas – User name – Password – Email address • Filters sensitive HTTP headers LPWA (ctd) Protects users from profile aggregation. \p (password).

secures data by hiding rather than encryption • Encryption is usually used as a first step before steganography Encrypted data looks like white noise Steganography hides this noise in other data • By replacing existing noise • By using it as a model to generate innocuous-looking data Hiding Information in Noise All data from analogue sources contains noise • Background noise • Sampling/quantisation error • Equipment/switching noise Extract the natural noise and replace it with synthetic noise • Replace least significant bit(s) • Spread-spectrum coding • Various other modulation techniques Examples of channels • Digital images (PhotoCD. PNG) • Sound (WAV files) • ISDN voice data . BMP. GIF.Steganography From the Greek for “hidden writing”.

Generating Synthetic Data Usually only has to fool automated scanners • Needs to be good enough to get past their detection threshold Two variants • Use a statistical model of the target language to generate plausible-looking data – “Wants to apply more or right is better than this mechanism. – Works like a text compressor in reverse – Can be made arbrtrarily close to real text Generating Synthetic Data (ctd) • Use a grammatical model of actual text to build plausiblesounding data – “{Steganography|Stego} provides a {means|mechanism} for {hiding|encoding} {hidden|secret} {data|information} in {plain|open} {view|sight}”. the lower the bandwidth Main use is as an argument against crypto restrictions . This mechanism is later years”. When leaving. Our only way is surrounded by radio station. – More work than the statistical model method. but can provide a virtually undetectable channel Problems with steganography • The better the steganography.

Uses redundancy in image/sound to encode information Requirements
• • • • • • Invisibility Little effect on compressability Robustness High detection reliability Security Inexpensive

Watermarking (ctd)
Watermark insertion

Watermarking (ctd)
Watermark detection/checking

Watermarking (ctd)
Public watermarking
• Anyone can detect/view the watermark (and try to remove it)

Private watermarking
• Creator can demonstrate ownership using a secret key

Copy Protection Working Group (CPTWG) looking at standardisation, http://www.dvcc.com/dhsg

Defeating Watermarking
Lossy compression (JPEG) Resizing Noise insertion (print+scan) Cropping Interpretation attacks (neutralise ownership evidence) Automated anti-watermarking software available (eg UnZign)

Defeating Watermarking (ctd)
Presentation attacks (segmented images)

Watermarking is still in its infancy
• No watermarking standards • No indication of security/benchmarks • No legal recognition

Other Crypto Applications
• Requires finding a collision for n bits of a hash function – “Find a message for which the last 16 bits of the SHA-1 hash are 1F23” • Forces a program to expend a (configurable) amount of effort before access is granted to a system or service • Useful for stopping denial-of-service attacks – n varies as the system load goes up or down – Can be used as a spam-blocker

Other Crypto Applications (ctd)
PGP Moose
• Signs all postings to moderated newsgroups – Signature is added to the message as an X-Auth header • Unsigned messages (spam, forgeries) are automatically cancelled • Has so far proven 100% effective in stopping newsgroup spam/forgeries

Crypto Politics and Export Controls
In God we trust. All others we monitor — NSA motto

Crypto Politics
It's almost impossible to avoid this Some larger companies have special legal divisions set up just for this Any real policy information is obtained through (US) freedom of information act (FOIA) lawsuits rather than official press releases
• Claimed policy and actual policy are often complete opposites

Data Storage vs Session Encryption Key Recovery
Legitimate need for stored data recovery in case of accident/lost keys/termination of employment
• Use secret sharing scheme for emergency access

No legitimate need (or commercial incentive) for communications session recovery
• If there’s a problem, re-transmit the data

Strong push by governments to convince companies that data storage recovery = communications recovery
• Key recovery has been given so many names (key escrow, law enforcement access, key recovery, data recovery, trusted third parties, etc etc) that it’s now known by the general term GAK (Government Access to Keys)

Early History
1977 1978 1979 1982 1984 1986 NSA tried to block NSF funding of crypto research Attempt to intimidate IEEE over security conference NSA uses Invention Secrecy Act to classify crypto patents Bobby Ray Inman’s “The sky is falling” speech: NSA should control crypto research NSA blocked NBS request for public-key equivalent of DES NSDD-145 moves control of computer security from NBS to NSA (NSA memo calls NSDD-145 “NSA-engineered”) NSDD-145 extended to allow NSA jurisdiction over private databases (Dialog, Compuserve) NSA tries to decertify DES CCEP (Commercial COMSEC Endorsement Program) using NSA-designed tamperproof hardware (eg Blacker)

Early History (ctd)
1987 1988 1989 1990 1991 Computer Security Act moved control of crypto back to NBS NSA tries to block publication of Khufu block cipher NSA/NIST memorandum of understanding moves control of crypto back to the NSA NSA designs signature-only PKC for NIST, begins work on Clipper NIST announces DSS and NSA-designed SHS Industry reaction was almost universally negative

Digital Telephony
Law Enforcement Requirements for the Surveillance of Electronic Communications, 1992
• Real-time, full-time monitoring capability • Intercepts undetectable to all parties (including service providers) • Multiple simultaneous intercepts possible • Decoding or decryption of all communications • Supplementary information provided is: – Directory number, associated directory number, line equipment number, call type/bearer capability, service profile identifier, PBX directory number, PBX station identifier, electronic serial number (ESN), mobile identification number (MIN), termainl equipment identifier, and service site information (for cellphone tracking)

Digital Telephony FBI spent two years promoting it (Operation Root Canal) Digital Telephony & Privacy Improvement Act passed as Communications Assistance for Law Enforcement Act (CALEA). pays AT&T to retrofit them with Clipper 15 April 1993. a commercial DESencrypted phone add-on The NSA goes ballistic • NSA convinces AT&T to use Clipper in the TSD in exchange for guaranteed government purchases • US government buys entire DES-based TSD production run of 9000. then LEAF. White House announces Clipper • CCEP laundered for public acceptability • Third-party access guaranteed through Law Enforcement Access Field (LEAF) – Originally LEEF. now DRF . October 1994. • FBI cost estimate (1992-1994): $150M $300M $500M • Industry cost estimate (1994): $3B • More recent study (1998): $8B per year – $12M per court-approved wiretap CALEA still isn’t reality • Cost • Technical difficulty Clipper 1992 AT&T announces the AT&T 3600 Telephone Security Device (TSD).

not for security/privacy .Clipper (ctd) 128-bit LEAF contains session key encrypted with Clipper family key and per-chip key Clipper (ctd) Clipper in operation • • • • Other party and third party decrypt LEAF with family key Both use checksum to detect bogus LEAF Third party looks up chip key in database. decrypts session key To increase public acceptability the key database is stored by two different agencies • Communicate secure in the knowledge that only the worlds largest spy agency is listening – Capstone documents are marked “Top Secret Umbra” = coded for signals intelligence.

only 2 were supportive Clipper adopted as Escrowed Encryption Standard (EES).Clipper Weaknesses 80-bit key is too weak Skipjack algorithm used in Clipper had no public scrutiny 16-bit checksum can be defeated Cipher operation mode (OFB) allows message forgery Chip ID served to neatly tag and identify every communication Reaction to Clipper 80% of Americans opposed it Of over 300 submissions. in February 1994 • The legal machinations required to get this adopted fill a 200page law journal article Noone bought Clipper • AT&T shut down its product line • FOIA’d documents obtained later showed that the government had a secret key escrow policy which was the exact opposite of the publicly claimed Clipper policy . FIPS 185.

device = smart card 1993 = MOSAIC. NSA-designed block cipher Specifics were a moving target 1991 = Pre Message Security Protocol (PMSP).Fortezza Based on Capstone (Clipper + DH + DSA + SHA) • Key exchange uses KEA. Oracle received $5M encouragement each) • Fortezza cards are expensive – $70 each for the government – ~$250 each for everyone else • Cards require PCMCIA readers and software – Have to shut down workstation to insert/remove card – Fortezza drivers conflict with other PCMCIA drivers • Attempts were made to sell Fortezza to foreign governments Later Fortezza versions removed GAK and added more useful (but classified) ciphers (eg Baton) . the DoD’s Internet • DMS provided financial encouragement for Fortezza (Netscape. modified DH/DSA • Data encryption uses Skipjack. device = Tessera card 1994 = Multi-Level Information Systems Security Initiative (MISSI) Later = Fortezza Fortezza (ctd) Used to implement MSP in the Defence Message System (DMS).

can’t be implemented as per the specification Post-Clipper Crypto Restrictions Commercial key escrow.Skipjack Skipjack and KEA were declassified in early 1998 • Expensive and scarce hardware necessitated software implementations. June 1995 • Anti-Electronic Racketeering Act – Outlaw distribution of encryption software Clipper II. which would have been reverse-engineered • Release was a denial-of-service attack on the worlds cryptographers • 32-round. January 1996 • 64-bit key with 24 bits held by the NSA • Swedish government didn’t discover this until 1998 . November 1995 • Software key escrow • Up to 64-bit exportable with backdoors Lotus Notes. fairly conventional block cipher – Breakable if limited to 31 rounds • Implementations were available worldwide within hours • KEA specification contains errors.

Post-Clipper Crypto Restrictions (ctd) Policy laundering. May 1996 • More escrow based on X. 1996 • Persuade the OECD to adopt US-style restrictions • Special OECD ambassador appointed to lobby OECD nations • OECD rejected US position Clipper 3. there’d be no way to manage them After 1996.1. an endless series of trivial revisions to Clipper 3. July 1996 • Even more software escrow • Allow export now if you build in backdoors later – Even if backdoors were available now. May 1996 • Don’t restrict crypto • Allow DES export • Crypto debate can be carried out in public Post-Clipper Crypto Restrictions (ctd) Clipper 3.x • “Dance of the seven (hundred) veils” .509 NRC report.

some governments pacified with occasional specialcase exports when they complain loudly enough Only software companies losing foreign sales and civil liberties groups now remain US to Relax Export Controls This exact same announcement has been made (on average) every three months since April 1994 • The pace has accelerated in the last year or two The same DES export announcement has been recycled more than half a dozen times • “encryption products using keys of up to 56 bits will be allowed for export” • “a relaxation of controls for non-recovery encryption products up to 56-bit key length DES” • “allowed export of encryption whose keys are as long as 56 bits” (one is from 1996.Boiling the Frog Intent is to buy off the loudest opponents until only the ones who can be safely ignored remain • Banks and financial institutions pacified with SGC • Fortune 500 pacified with special export dispensations • Subsidiaries of US companies pacified with case-by-case export of strong crypto • Hospitals. one from 1998) . one from 1997.

. dozens of export control press releases later. It’ll change • If there’s a rule you like. In 1999 you still can’t buy general-purpose strong crypto from the US Export Controls The four rules of US export controls 1. you go to jail 4.. The enforcers have no sense of humour Corollary • If there’s a rule you don’t like. wait. It’ll change . They don’t make any sense 2. If you get it wrong..US to Relax Export Controls (ctd) In 1994 you couldn’t buy general-purpose strong crypto from the US .. They change constantly 3. wait.

1933 (based on the Trading with the Enemy Act. then moved the boundary markers into a swamp once they’d signed the cheque US Export Controls (ctd) Export controls don’t exist as a conventional law • In the third week of August of each year. 1917). the charade is repeated • The constitutionality of this has been called into question . the US president declares a national emergency under the International Emergency Economic Powers Act.US Export Controls Based on International Traffic in Arms Regulations (ITAR). with the duration of the emergency being one year – The emergency being used is the Great Depression • Using the powers given to him by the act. he issues a presidential decree which extends the export controls for another year • The following year at the same time. 1943 law designed to stop Nazi Germany and Imperial Japan from obtaining US technology Redone as EAR (Export Administration Regulations) in 1996 • ITAR was handled by the State Department who allowed almost nothing out • Intent of EAR was to transfer controls to the more businessfriendly Commerce Department – Unfortunately the State Department baggage came with them – Government showed software companies a piece of prime real estate.

.x and 5.x) but. Effects of Export Controls (ctd) Export controls are highly effective in ensuring that the masses have no real security • The majority of all crypto in use worldwide is crippled or broken – 77% of Thawte users are using weak encryption – 60% of them are in the US – For most of its existence.. Verisign issued weak (512-bit) keys to users outside and inside the US .Effects of Export Controls Export controls are completely ineffective in stopping anyone from acquiring any type of encryption • Anyone who wants it can get strong encryption anywhere within minutes • Average public key sizes used when users have a choice – 1024 bits in 1996 – 2048 bits in 1998 • (corresponding to the default “strong” encryption key size in PGP 2.

000 hits • RSADSI claims 300 million RSA products are used worldwide Controls lead to lost sales and slowed growth in encryption-dependent industries Cost savings due to intranets and extranets can’t be realised Economic Strategy Institute report estimates the US crypto policy will cost US industry $50B in 2003.Effects of Export Controls (ctd) In practice. but sales which require crypto are in the hundreds of billions • 500 non-US firms sell 700 crypto products • A web search for encryption produced over 50. The breach came to light when officials believed that American negotiators had been given advance warning of confidential European Union positions in last year’s trade negotiations” “They were able to exploit the fact that parts of the system were manufactured by two American firms” Economic Effects of Controls The worldwide crypto market is in the low billions. everyone else has weak encryption Practical example of export control effects is demonstrated by CIA hacking into European parliament computers in 1996 (Sunday Times): “includes details of the private medical and financial records of many MEPs and officials. including trade. tariff and quota agreements. US companies have strong encryption. $65B in 2004 • Imposing GAK would cost $140B as everyone switched to foreign products . and discussion documents on confidential issues.

“loi 90-1170 du 29 decembre 1990” requires approval for encryption use from the Prime Minister – “If you don’t tell us you’re using PGP. we will refuse” — J. encryption is rated 2 – Netscape is the second most dangerous weapon type recognised by the French government • Modified constantly over the years. If you ask us for permission to use it. “decret 86-250 du 18 fev 1986” explicitly mentions encryption software. Vincent-Carrefour. 1996 • Export controls prevent the teaching of crypto to foreign students (still being decided) French and Russian Crypto Controls French controls are based on the “decret de 18 avril 1939” • On a scale of 1 to 8. head of the SCSSI . noone will bother you. 1995 • ITAR/EAR is unconstitutional since it violates the First Amendment Junger Case.Legal Challenges to US Controls Three main challenges. 1995 • “Applied Cryptography” can be exported as a book but not as a floppy disk Bernstein Case. intent is to get a Supreme Court ruling on export controls Karn Case.

and by extension all businesses dealing with that. use only FAPSI-approved encryption • Provides a nice guaranteed money-earner for the (ex-)KGB.French and Russian Crypto Controls (ctd) • Companies big enough to afford it would go to some lengths to sidestep the controls – Daily couriers carried information from Paris to London – Information was encrypted and sent to corporate HQ – Replies were decrypted and carried back to Paris • 40-bit encryption was allowed in 1996 after a French researcher demonstrated how easy it was to break French controls were removed in 1999 after publication of a European Parliament report detailing massive US communications interception and surveillance initiatives in Europe (Echelon) • Sole effect of controls was to make US industrial espionage easier French and Russian Crypto Controls (ctd) Russian controls created by presidential decree (ukaz). Individuals and companies openly use and sell encryption with no repercussions . “The severity of Russian law is compensated for by it’s non-mandatoryness”. a department of the (former) KGB • Requires that all commercial banks dealing with the Central Bank of Russia. April 1995 • Places encryption under the control of Federal Agency for Governmental Communications and Information (FAPSI).

Regarded as archaic and unrealistic • Run from the US embassy in Paris. fax machines. etc.Non-US controls Based on Cold War COCOM controls • Predated PC’s. seen as merely an extension of the US State Department – COCOM-era “New Zealands Export Controls” are actually US documents with US wording and spelling • Growing resentment in Europe where controls were seen as US-imposed trade barriers Wassenaar and Software Export COCOM was disbanded in March 1994. Wassenaar created blanket exceptions for public domain and massmarket software • Software exceptions are implemented via the General Software Note (GSN) . of which one is to “not impede bona fide civil transactions” In recognition of COCOM’s unrealistic nature. the Internet. reformed as the Wassenaar Arrangement in November 1996 • Wassenaar = COCOM with the section numbers changed (and localised spelling) Wassenaar has four main purposes.

Generally available to the public by being: 1. Sold from stock at retail selling points. Telephone order transactions. by means of: a. Designed for installation by the user without further substantial support by the supplier. or b. or c. Mail order transactions. 'In the public domain' Wassenaar and Software Export (ctd) ‘In the public domain’ is defined as: 'Technology' or 'software' which has been made available without restrictions upon its further dissemination (copyright restrictions do no remove 'technology' or 'software' from being 'in the public domain') (‘technology’ and ‘software’ are further defined) This allows almost unrestricted crypto software export .Wassenaar and Software Export (ctd) General Software Note (GSN) (This note overrides any control within section D of Categories 0 to 9) Categories 0 to 9 of this list do not control 'software' which is either: a. and 2. Over-the-counter transactions. b. without restriction.

Australia and New Zealand altered it as follows: With the exception of Category 5. 1995 • Attempt to export US-exportable crypto device • Noone knew how to handle this “routine” export “Anyone trying to follow the regulations is forced to jump through pointless hoops so obscure that even the people charged with enforcing them don’t know what to make of them” “My life as a Kiwi arms courier”. 1998 • Noone in NZ knows what to do either . or by whom Enforcing the Controls “My life as an international arms courier”. Categories 0 to 9 of this list do not control 'software' which is either: The altered form of the Wassenaar text reverses the original intent and directly contravenes the requirement that the controls not impede bona fide exports • Noone has ever been able to explain why this alteration was made. Part 2 (Information Security).Doctoring Wassenaar After Wassenaar was finalised.

totalling hundreds of millions of dollars Menwith Hill World’s largest regional sigint interception centre (RSOC) Located in UK.200 US personnel Intercepts communications from all over Europe for transmission back to the US • 28 radomes • Outgoing comms capacity for 100. staffed by 1. this carried almost all UK long-distance calls in the 1970’s and 1980’s • NSA director Studeman statement on state of interception in 1992 – 2 million intercepted messages/hour – 17.5 billion intercepted messages/year .000 simultaneous phonecalls • Taps into UK microwave trunk at Hunters Stones.Enforcing the Controls (ctd) Typical effects of controls on US companies • “Order placed by large foreign company“ • “Advised that approval would be unlikely” • “Contract went to foreign competitor” There are hundreds of these cases.

NZ (Pacific satellites) .Menwith Hill (ctd) SILKWORTH • 56 satellites which intercept long-distance microwave links • Mercury. satellites controlled via the RUNWAY radomes MOONPENNY • Unauthorised interception of standard satellite communications Echelon US interception stations similar to Menwith Hill are scattered worldwide Intelsat • • • • • • Morwenstow. Mentor. Washington (Pacific satellites) Geraldton. West Australia (Indian ocean satellites) Waihopai. Trumpet. North Carolina (Atlantic satellites) Sugar Grove. West Virginia (Atlantic satellites) Yakima. UK (Atlantic satellites) Rossman.

Echelon (ctd) Other satellites • • • • • • • • Bad Aibling. Indian Ocean Tangimoana. New Zealand Currently around 120 satellite collection systems are in operation • 40 targeting western commercial communications satellites • 30 controlling space-based interception satellites • 50 targeting Soviet communications satellites (some have since been reassigned to commercial western satellites) . outside Ottawa Menwith Hill again Misawa. Australia Leitrim. outside Darwin Echelon (ctd) Radio • • • • Many sites in the US and UK Bamaga. Puerto Rico (US) Shoal Bay. Japan Sabana Seca. Australia Diego Garcia. Cornwall Kojarena. Germany Bude.

Kunia. UK – Bad Aibling. Bad Aibling. Hawaii Atlantic RSOC. Vortex intercept telecoms. Denver. Australia Information is collected and processed at Regional Sigint Operations Centres (RSOC) • • • • • European RSOC. launched by NRO – Ferret in 1960’s – Canyon. Fort Gordon. Georgia Pacific RSOC. Mentor. Germany – Pine Gap (Merino). Lackland AFB. Germany Central RSOC. Menwith Hill. Jumpseat in 1980’s – Mercury. Texas . and cellphone communications • Operated by CIA and NSA. Rhyolite. Trumpet intercepts cellphones • Britain (Project Zircon) and France (Project Zenon) have attempted similar schemes Echelon (ctd) • Ground stations located in – Buckley ANGB. microwave.Echelon (ctd) US satellites monitor terrestrial radio. Colorado – Menwith Hill. Vortex. Magnum. UK Southern RSOC. Aquacade in 1970’s – Chalet. Orion. Trumpet in 1990’s – Cost ~$1B each • Orion.

faxes. digitalmicrowave) Modem signals can be demodulated in software using a Pentium MMX/MicroSparc .Echelon (ctd) Stations intercept private phonecalls. telexes. and other communications and forward them to the NSA All communications are automatically scanned for keywords (PATHFINDER at Menwith Hill) and/or voice patterns (VOICECAST at Menwith Hill) • Economic information is forwarded to US companies by the Office of Intelligence Liason • Preferential beneficiaries are the defence contractors (Lockheed. Loral. Raytheon) who built Echelon Echelon is covered in the European Parliament reports “Assessing the Technologies of Political Control” and “Interception Capabilities 2000” Blind Signal Demodulation Signal demodulation without the cooperation of the sender/receiver Avoids the need for adapative equalisation or other initialisation and training • Automatically adapts to modulation techniques such as QAM • Can adapt to unknown baud rates (V. TRW. emails. Boeing.34 can employ any of six symbol rates) • A decade ago this was regarded as impossible to do Implemented in standard DSP hardware (modems) or ASICs (digital video.

cellphone. fax. trainon-data capability. voice data decoded and ready for use – “VGC content identification.42bis compression.Blind Signal Demodulation (ctd) Typical commercial blind demodulation equipment • Voice Channel Demodulator – Input = E1 or E3 – Output = all leased-line and dialup modem. IF signals. and Internet protocols like POP for a modem link) decoded Blind Signal Demodulation (ctd) • Signals Analysis Workstation – Input = Any type of link signal (FDM basebands. fax. and digital data signals with all data and protocols (eg V. voice. DS1 bitstreams. PCM bitstreams. pager. PPP. Ethernet) – Output = modem. Easy to use GUI with extensive online help” • Ex-NSA satellite interception gear is occasionally sold as surplus . signalling recognition.

crews have received similar commendations (noone knows what for) . most accurate adaptive information filtering system in the world” • Typical application compares 1GB of data against 50.000 to 12. a general method to retrieve data according to topic • “Find every document covering the same topic as this one” • System works on very large data sets and in presence of errors Undersea Cable Tapping Operation IVY BELLS tapped Soviet cables in the Sea of Okhotsk • Tapping occurred from 1972 to 1982. when an NSA employee sold the details to the Soviet Union • From 1979 to 1992 a cable in the Barents Sea was similarly tapped • Submarine crews who placed the taps earned presidential citations • Every year from 1994 to 1997.000 match profiles every day • Standard US test benchmark involves locating information about “Airbus subsidies” NSA-developed N-gram analysis.Data Analysis Custom hardware used to speed analysis • Paracel Fast Data Finder (FDF) contains 6.000 custom processors • “The fastest.

Echelon in Action
German company Enercon GmbH develops a new type of wind energy generator Shortly afterwards, US company Kennetech filed a patent for exactly identical technology in the US
• Obtained a court order preventing Enercon from operating in the US

Loss to Enercon: 100 million DM, 300 jobs
• Enercon now uses secure communications methods

Enercon data was probably intercepted via the NSA RSOC in Bad Aibling, Germany
• GCHQ ordered UK patent office to use 256-bit public-key encryption to communicate with European patent office in Munich, Enercon may have been using similar “security”

Other Typical Echelon Uses
• Aiding transfer of $200M Indonesian deal from NEC to AT&T (Der Spiegel) • Forwarding details of Thomson-CSF deal in Brazil to Raytheon (Baltimore Sun) • Obtaining Japanese research on advanced automobiles for Ford, GM, and Chrysler (Mainichi) • Providing information to US negotiators facing Japanese car companies in trade dispute (New York Times) • Providing information on APEC deals to Democratic Party campaign contributors (Insight Magazine) • Intercepting Mexican trade representatives during NAFTA negotiations (Financial Post (Canada)) • Intercepting Canadian negotiations for sale of 3 reactors to South Korea (Financial Post (Canada)) • Monitoring activities of Robert Maxwell (Financial Mail (UK))

Other Typical Echelon Uses (ctd)
NSA also targets private individuals
• NSA maintained 1,056 pages of files on Princess Diana (Washington Post) • NSA produced 39 internal publications on Diana • Information was collected over a period of years • “NSA systematically intercepts international communications, both voice and cable” — NSA Director Lt.General Lew Allen testifying before Congress

Other Typical Echelon Uses (ctd)
“Within Europe, all email, telephone, and fax communications are routinely intercepted by the United States National Security Agency” — European Parliament report “Assessing the Technologies of Political Control” • This report prompted the French government to remove its crypto restrictions “The end of the Cold War has not brought to an end the Echelon eavesdropping system. This system has become a weapon of economic warfare” — Rossiyskaya Gazeta (Russian state-funded daily paper) Echelon is “this incredible communications vaccuum cleaner” — Il Mondo

Other Typical Echelon Uses (ctd)
“Former intelligence officials say tips based on spying […] regularly flow from the Commerce Department to US companies to help them win contracts overseas” — The Baltimore Sun

Interception Capabilities 2000
European parliament report on Echelon
• Annual communications interception budget = $15-20 billion • “Comprehensive systems exist to access, intercept and process every important modern form of communications, with few exceptions” • Intent of US diplomatic initiatives over crypto controls was motivated by intelligence collection requirements, “a long-term program which undermines the communications privacy of European governments, companies, and citizens” • “Documents obtained under the Freedom of Information Act indicate that [crypto] policymaking was led exclusively by NSA officials, sometimes to the complete exclusion of police or judicial officials”

Echelon and Export Controls
With the end of the cold war, intelligence agency concerns switched from INFOSEC and COMSEC to JOBSEC Increasingly, economic and industrial data rather than military data was targeted
• Some countries had been doing this for decades • Intelligence agencies feed information obtained from foreign companies back to favoured local companies – Whole books have been written about these things • If crypto were freely available, this goldmine of economic, industrial, and trade information would dry up – Despite the rhetoric about terrorists and pornographers and other bogeymen, it’s really about money

Echelon and Export Controls (ctd)
Export controls are utterly ineffective on an individual basis, but extremely effective for blanket surveillance and espionage
• Export controls help criminals and terrorists by leaving information systems vulnerable to attack

If crypto becomes widespread, the spooks will lose a $x00million-dollar investment in surveillance technology
• The export controls will never go away if the spooks can help it

“The real aim of current policy is to ensure the continued effectiveness of US information warfare assets against individuals, businesses and governments in Europe and elsewhere” — Ross Anderson

Cloud Cover
Confidentiality Key Infrastructure (CKI) Designed by CESG, the trading name of GCHQ Design goals
• PKI provides trust infrastructure for keys • CKI provides backdoor access infrastructure for keys

Cloud Cover (ctd)
CA’s are replaced by certificate management authorities (CMA’s)
• • • • CMA’s provide shared key generation capability Can recover the confidentiality keys used by both parties Can recover signature keys distributed via confidentiality keys Can revoke the ability of parties to communicate in private

CMA’s were referred to as “trusted third parties”, yet another new synonym for GAK

Problems with Cloud Cover
Provides no benefit over PKI, and many liabilities Very complex protocol
• Generation of a simple shared key is a laborious, multi-step process • Nothing works without the CMA’s cooperation

Assumes the only threat is from outsiders
• UK security incident statistics show ~95% of attacks are by insiders • Cloud Cover facilitates these attacks immensely

Problems with Cloud Cover (ctd)
Attempt made to sell Cloud Cover to the National Health Service (NHS)
• Rejected by the British Medical Association and NHS

Flaws found in the protocol
• Still being pushed by CESG in hospital “pilot projects”

DTI Proposals
Only GAK CA’s (and signatures) will be recognised by law Government is allowed secret access to GAK’d keys
• Access is granted by request, not by court-ordered warrant • GAK accesses/usage must be kept secret

Non-UK (non-GAK) signatures will not be recognised
• Under the EU digital signature reciprocity rules, UK signatures will not be recognised anywhere else • “We need to make sure all our laws and rules are e-commerce friendly”

DTI Proposals (ctd)
UK companies/individuals are given a choice:
• Submit to warrantless secret surveillance of private communications or • Opt out of e-commerce

“This is not mandatory key escrow” DTI were awarded the 1998 Big Brother Award (national government category) for their efforts

radio communications have no expectation of privacy . usually in real time • After 10 years of work on X. there is no technical method from preventing this” — NSA study on key recovery Many keys can’t be GAK’d • Session keys are set up and discarded on the fly • Securely transporting this continuous flood of keys to a GAK centre is practically impossible GAK Problems (ctd) Building the infrastructure is well beyond the state of the art • Law enforcement requires 24/7 access to keys.509 we can’t even move public keys around yet Handing over keys demonstrates a lack of presumption of privacy  no warrant necessary • ECPA ruled that cordless phones.GAK Problems Critically dependent on the honesty of criminals in complying with GAK requirements Trivially defeated by • • • • Use of non-GAK software Double encryption with strong crypto hidden by GAK crypto Use of doctored GAK software (Clipper protocol failure) “If the sender and receiver collaborate to defeat KR [key recovery].

February 1998 • Rogue users will bypass any KR mechanism • Rogue KR agents/LE agents pose “the most formidable threat” Summary of report: GAK won’t have any effect on the bad guys. and greatly jeopardises the good guys • Governments will try to implement it anyway German government: “A US-style ‘key recovery’ system cannot be reconciled with national security interests” GAK in Practice Example of centrally-managed key centre: Bank with 25.000 employees • Used centrally-managed mainframe passwords • 30 full-time employees barely coped GAK schemes are vastly more complex than this simple password example Conservative US estimate is 90M keys escrowed per year • Using the banking key centre figures.000 people to manage • A secret shared by 100.NSA Study on Key Recovery “Threat and Vulnerability Model for Key Recovery”. this would require 100.000 people isn’t terribly secret .

GAK in Practice (ctd) The fact that GAK is so far beyond the state of the art is probably the biggest protection against it being implemented any time soon .