Incidents of the Week Wikileaks disclosure of unedited cables - - PowerPoint PPT Presentation

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

Design Policies 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 1 Random (slight preference for 1)

X

1 Random Random Random (slight 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

• r

Using photon polarization

= ? (equal probability)

• r

=

• r

? (equal probability)

measure diagonal measure square 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

CPU cache memory CPU core Main memory Every modern CPU has an on-board memory cache The content of this cache survives process switches Thus, we can learn something about another processes’ memory access

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

Source code vs. Implementation errors

• Industry Average: about 15 - 50 errors per 1000 lines of delivered

code.

• Microsoft Applications: about 10 - 20 defects per 1000 lines of code

during in-house testing, and 0.5 defect per in released product

• ‘Cleanroom development‘ : 3 defects per 1000 lines of code during

in-house testing and 0.1 defect per 1000 lines of code in released

Product Source Lines of Code (in millions) Linux Kernel 2.6.32 12.6 Windows Vista 50 F35 Joint Strike Fighter 5.7 S-Class Mercedes 20 Apollo Lunar Mission 2

If coding safely is hard, what about security ?

• It is near to impossible to write bug free (let alone

secure) code of more than 10s of thousand lines of sourcecode

• Most real attacks are wrong attacking

implementations, not designs

• A determined and qualified attacker will get you

– Even if you did everything right, you probably have to use external software as well (BIOS, Compiler, firmware, …)

• That’s sad, but we have to live with it:

Everyone claiming his product is secure is lying! (or marketing)

• But we can

– Lower the attack surface

• Make it harder for an attacker to find an exploit
• Make it uneconomic for many attackers to target us

– Keep the effects of bugs contained

• This is part of secure design & policies