Incidents of the Week • Wikileaks disclosure of unedited cables • DigiNotar fake certificates
Wikileaks: What Happened • Wikileaks disclosed unedited version of leaked cables to The Guardian • Encrypted file was hidden in the filestructure of the Wikileaks web server, password and location give to Journalist • To assure availability of Wikileaks files, the entire filesystem was replicated via Bittorrent • The Journalist published the full password in his book on wikileaks • Disgruntled Wikileaks members revealed that the files and key where ‘out there’ • One Newspaper published this; more quickly assembled the pieces • After a Twitter vote, Wikileaks decided to publish everything ?
Wikileaks: What went wrong ? • Security by obscurity (file hidden in the filesystem), which consequently broke • Different people had different expectations – Journalist thought the file would be removed – Wikileaks expected he’d keep the password secret • Massive replication prevented Wikileaks from fixing the problem once they knew about it
Lessons to be learned • The problem is between the ears – User issue, not a technology one • Unspecified behavior of subsystems – Everyone assumed something about the others’ behaviour • Security by Obscurity – Critical file “hidden deep in the filesystem ” • Confidentiality vs Availability – Choose one • Poor policies – Passwords must NEVER be published – Easyer now to guess related passwords “ACollectionOfDiplomaticHistorySince_1966_ToThe_PresentDay#” • Insider attacks are the main source where things go wrong
SSL Root Certificates Root Certificate public keys stored in your browser. 50 in Firefox 100 in Internet Explorer
So what did happen ? • July 10, DigiNotar issued a (false certificate for ‘google.com • July 19, they discovered an intrusion on their certification system, and revoked 128 certificates • July 20, another 129 false certificates where detected and revoked the day later • July 27, 75 more false certificates where detected and revoked • Aug 28, a fraudulent google.com cerfiticate issued by DigiNotar was detected in the wild because of the Chrome browsers ‘pinning’ feature • August 29, the DigiNotar Root Certificate was removed from Mozilla and Internet Explorer • A Post mortem found 531 forged certificates and up to 300.000 affected users
What went Wrong • Root Certificate issuer is extremely critical component of SSL Certification structure. – The least secure issuer determines security of the whole system • Poor Information policy – faked certificate where known long before – Issuer thought they could handle this, but couldn’t • Apparently insufficient security in spite of audits (this is subject to ongoing investigations)
Lessons/Consequences • The Root-Certificate Structure of SSL is flawed – As secure as the worse Root CA • Keeping issues a secret can make the worse (and bankrupt your company) • Attack originated from Iran; if this is true, thousands of dissidents are in danger
Assignment • Read the FOX-IT post mortem analysis http://www.cs.ru.nl/~klaus/SiO2011/Assignments/rapport.pdf • Sum up (one paragraph) what went wrong (in addition to what is mentioned on the previous slide) • Think of one architecture measure that could have helped preventing such an issue • This is non graded, but be prepared to discuss your results next week (groups of up to 5 people are allowed)
Secure Software development
Scope • What this lecture is about – Getting an understanding on the issues and principles behind secure software design – Understanding what not to do yourselfs • What it is not – Teaching you how to write secure code • Eric Poll is doing that – Teaching how to design secure systems • That’d take much more time
The Software Security Blocks Policies Design Implementation
Implementation Security
• Implementation of security code – Authentication, Encryption, everything that handles keys – This code is special, as it is the primary attack target, and handles all your secrets • Secure Implementation of normal code – Avoid buffer overflows and other vulnerabilities
Why Implementations matter • Quantum Key Exchange: Proven theoretically secure • AES: Assumed mostly secure
Quantum Key Exchange 101 Instead of normal Bits (0,1), we have Qbits: Qbits cannot be measured directly, but only with respect to a base. After measurement, they will be aligned with the base Basis Random Random 0 1 Random (slight + preference for 1) 1 0 Random Random Random (slight X preference for 1)
Quantum Key exchange Physical laws of quantum mechanics: • Qbits cannot be copied in their exact state • Measurement alligns the qbits with the base they are measured on, i.e., measuring with the X base, results in or
Using photon polarization ? (equal probability) = or = or ? (equal probability) measure measure square diagonal destroys state
The Key Exchange Any eavesdropper will have a 50% change to measure wrongly, and thus destroy the state. This will be discovered by Bob.
Why is this so great ? • Provable security based on laws of physics • Information theoretic security: No surprise advances in mathematics possible • Commercially available now!
And why is it not ? • Wrong problem solved – Generated shared keys between two high secure facilities is not our main issue • All actual implementations have been broken!
What went wrong ? • Security proofs depend on a particular model • This model does not correspond to reality • Especially physical systems rarely fit into mathematical models – Forgotten properties • sidechannels Photons are usually send in bursts • possibility of fault insertion It is possible to ‘blind’ the photon detector – Imperfect implementations
Mid - Summary • Just because a scheme is provably secure, it does not mean its implementations are. • Especially hardware attacks usually can use features not part of the model • Now for software implementations…
Example Crypto Algorithm: AES
Example Crypto Algorithm: AES
The AES design is considered secure, and it is fairly easy to implement… so where’s the catch ? Implementing AES securely is difficult!
Issue 1: Wrong use of AES (1)
Issue 1: Wrong usage of AES (2) Using plain AES, all equal blocks result in equal encrypted blocks
Ciphermodes CBC • No parallelization in the encryption possible • Errors in the cipher text only propagate one block
Ciphermodes (2) • Easy to parallelize • Cheaper to implement in Hardware (Enc. Only) • One wrong bit in ciphertext results in one wrong bit in plaintext
Issue 2: Wrong Assumptions • E.g., authentication • Primary example: CTR Mode of operation: – I cannot decrypt, but I can change bits in the encrypted text – This way, I can either fake messages, or use the system as an oracle on what the bit was
Attack 1: Shamir-Tromer Attack Every modern CPU has an on-board Main memory cache memory The content of this cache survives process switches CPU Thus, we can learn something about cache another processes’ memory access memory CPU core
Attack 1:Shamir-Tromer attack S is actually a fairly big table Knowing which part of S was accesses, I learn something about the internal state of the cipher How do I do this ? • Have one process running in parallel to the AES one • Overwrite some part of the cache used for S with my own data • Let the AES process run a little • Check if my data is still in the cache Result: Stealing a key used by the Open SSL AES implementation in 35ms (300 encryptions).
Attack 2: Finding the Key/Code in Memory • Shamir, van Someren: If you find 128 bit of real random data, this likely is a key • Klein: Look for standard key storage structures • AES implementation has very specific code, easy to recognize – Even better now: Intel CPUs have AES command
Attack 3: Simple Fault insertion
Attack 3: Simple fault insertion S is publically known What happens if I look for S on my harddisk, and replace it with 0 ? • The output of SubBytes is 0 • The input to AddRoundKey is 0 • The output of AddRoundKey is secret_key 0 • On this PC, there are 13 vulnerable AES implementations
And many, many more attacks Cache collision, timing based, heat measurements, sound measurement, differential power analysis, electro-magnetic analysis, branch-timing, memory-fault, fault insertion, cold-boot, swap space, firewire DMA attacks, statistical key search, probing attacks, clock glitches, or any combination thereof.
Courtesy to Ross Anderson
Implementation issues in practice Microsoft Xbox: • Used bad hash-function twice – First RC4, then TEA – Allowed attacker to fake signatures • Relied on wrong assumptions on hardware – Allowed attacker to execute code in RAM Sony PS/3 • Reused randomness for signature scheme (DSA) – This allowed to compute the secret key
Coding Securely Coding safely is HARD Even without any malice
Recommend
More recommend
