secure development deploying crypto in the real worldaz9194.vo.msecnd.net/pdfs/110902/3382.pdf ·...

SECURE DEVELOPMENT

DEPLOYING CRYPTO INTHE REAL WORLD

Insert presenter logo

here on slide master

Dan Houser, CISSP-ISSAP CISA CISM CGEIT

Member, (ISC)² Board of Directors

Security & Identity Architect, Cardinal Health

Session Classification: Intermediate

• Cardinal Health, Inc. is a Fortune 17 company that improves the cost-effectiveness of health care.

• The business behind health care

CARDINAL HEALTH... NOT A HOSPITAL

Copyright © 2011 Daniel D. Houser

• The business behind health care

• More than 37,000 people worldwide.

• $100 Billion Revenue

• 390+ facilities in 90 countries

DISCLAIMER

• This presentation doesn't present any real-world cryptographic implementations at Cardinal Health, nor does this presentation represent statements of Cardinal Health policies or engineering regarding cryptography.

• Cryptography is tricky stuff, and merits consideration.

• This presentation isn't a complete guide to avoid being


• This presentation isn't a complete guide to avoid being burned by cryptography. Hire an expert.

• Do-it-yourself Crypto is as advisable as self-surgery

• This perspective is corporate cryptography, not national secrets

CRYPTOGRAPHY IN THE REAL WORLD

• Real-world cryptographic implementations, and lessons learned.

• Balancing security with expediency to deliver "good enough" crypto


“In theory there is no difference between theory

and practice.

In practice, there is.” -Yogi Berra

CRYPTOGRAPHY IS MATH

• Pretty formulas

• Theoretical, Logical

• Digital

• Sound premises lead to proof after proof


• Unassailable conclusions on paper

• 4000+ years old

• Means of turning coffee into tenure

11110000 XOR 10001110 = 01111110

INFORMATION SECURITY IS ENGINEERING

• Excess of overlapping measures, controls sufficient to overwhelm...

– Determined attackers

– Nature / Acts of God

– Idiots / Acts of Ignorance & Error


– Idiots / Acts of Ignorance & Error

• Layered defenses

• Dozens of years old

• Often poor tools & an indeterminate environment

• Constant change

• Problem: Engineers think they can solve for X

INFORMATION RISK MGMT IS ANALOG

• Even younger science

• Rough Economic Models

• ALE, RAROC

• Probabilistic Losses

$

SecurityExpense

Total cost

Loss


• People issues

• Balancing act

• Imperfect measures

Expense

SCMM

CYNIC’S VIEW OF CORPORATE CRYPTOGRAPHY IN CONTEXT

Perfect mathD – in imperfect algorithms, defined by incomplete requirements,

– implemented by lazy ADD developers, with 3rd party APIs,

– using unproven sample code from anonymous web sources,

– supplemented with low-bid contractors,

– through human processes, using flawed and incomplete testing,


– through human processes, using flawed and incomplete testing,

– on run-away projects to achieveD

– Incomplete measures of budgeted sufficiency,

– governed by managers who view security as a necessary evil,

– maintained by untrained, overworked admins,

– on buggy, general-purpose OS. Perfect.

CRYPTOGRAPHY IN CONTEXT

• From Deterministic to Probabilistic

• From Digital to Analog

• From Perfect Math to Perfect Mess

• Yields some Surprises


• Yields some Surprises

• Let’s look at some of the Mess & Surprises...

IS IT USING SSL?

• Perhaps the most over-used question in all of Information Security.

• SSL is not the magic elixir


• Overused because it

checks the box �

IS IT USING SSL?

SSL is typically a weak control – Why?

SSL Accomplishes Two Pragmatic Things:

1) Server Side Authentication

– So... why doesn't it solve phishing?


– So... why doesn't it solve phishing?

2) Link to link confidentiality (untrusted networks)

– Control where there is NO attack

– Zero provable ROI (return on investment)

– Lawyer Repellent

– Private keys are almost always in the clear

SSL & TLS support

anonymous mode

RFC2246 A.5 pg54

IS IT USING SSL?


RFC2246 A.5 pg54

The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated.

CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };

CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };

CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };

source: http://www.ietf.org/rfc/rfc2246.txt

SSL & TLS Support NULL crypto ciphers

In other words, Cleartext is a valid SSL mode

RFC2246 6.1 Connection States – pg14

TLS Security...Parameters are defined in the presentation language as:

IS IT USING SSL?


as:

enum { server, client } ConnectionEnd;

enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;

enum { stream, block } CipherType;

enum { true, false } IsExportable;

enum { null, md5, sha } MACAlgorithm;

enum { null(0), (255) } CompressionMethod;

http://www.ietf.org/rfc/rfc2246.txt

By default, TLS must support CipherSuite:

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

However, your server admins or developers may have

implemented:

IS IT USING SSL?


TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

OR

TLS_NULL_WITH_NULL_NULL

Not necessarily an issue for internal data center traffic – but

do you know??

BETTER QUESTIONS

� What business problem are you trying to solve?

� What are you protecting/ information value?

� What is the threat model?

� What compensating controls do/could exist?

� What properties of cryptography are desired?

Confidentiality/ Integrity/ non-repudiation


Confidentiality/ Integrity/ non-repudiation

� What is the level of assurance needed/provided?

� How are you using SSH/SSL?

� How are you creating, protecting & managing keys through the entire lifecycle?

See appendix, similar coverage SSH�

DES ≅≅≅≅ 3DES ≅≅≅≅ AES

“If the use of DES is your weakest control, then your site is very secure indeed” - Bill Murray

We spend too much time arguing protocols, not nearly enough time discussing:


– Key controls and key management

– Key change/exchange procedures

– Cryptographic toolkits

– Random number/seed generators

– Process & documentation

– Training

KEY STRENGTH IS OVERRATED

• Arguing over 512 bits, 1024 bits and 4096 bits...

...is like upgrading the lock on your tent

• Thieves don't pick locks (except on television)

• Again, much more important to worry about:


– Key management

– Key exchange protocols

– Avoiding key re-use

– Cryptosystem DRP/BCP

– Repeatable, documented processes

– Training of crypto personnel

NOBODY* BRUTE FORCES CRYPTO

“We always cheat. We never go after the algorithm. We always go after the implementation, and it works.”

- Ben Jun, VP Cryptography Research


- Ben Jun, VP Cryptography Research

*except governments & media/warez pirates

NOBODY BRUTE FORCES CRYPTO

• Brute force is too expensive

• Cryptosystems fail due to implementation flaws


• WEP – failed due to implementation, not RC4

• CSS – failed implementation, cleartext key

• Enigma – bad practices, poor key choice

• Hint: You don’t want your software listed here...

TOOLKITS MATTER. A LOT.

• LOTS of ways to screw up cryptographic implementations

• Key functions in toolkits can provide substantial armouring of cryptosystems

• Great skill is required to achieve comparable


• Great skill is required to achieve comparable protection using default language libraries

• Use crypto toolkits such as Bouncy Castle, RSA BSAFE, MS-CAPI, OWASP ESAPI

I HAVE THIS HOBBY THAT GIVES ME PERSPECTIVE…

Copyright © 2011 Daniel D. Houser21

EVEN GREAT TOOLKITS ARE DANGEROUS

• Easy to make mistakes constructing your own crypto system, despite a good toolkit

• Exceedingly difficult to test well.

• Think Do-it-Yourself firearms @ 70,000psi


1. Buy a crypto system (e.g. PGP)

2. If you cannot, buy tools (e.g. BSAFE) and retain cryptographic services

3. Never build your own crypto code if possible

4. NEVER create your own primitives (algorithms)

CRYPTOGRAPHERS ARE SMART PEOPLE

• The converse is almost always wrong:

Smart People != cryptographers

• Just because they're brilliant at math, physics, programming or chess doesn't make them a cryptographer


• Snipers don’t make good combat armor

• Pharmacists don’t invent life-saving drugs

• Truck drivers don’t design good bridges

CRYPTOGRAPHERS ARE SMART PEOPLE

• If you're doing custom crypto, stop.

• If you don't listen, then at least have it certified by a cryptographer.

• Cryptographers, cryptanalysts, cryptologists, and cryptographic implementers are different.


cryptographic implementers are different.

• Know the difference. Hire the right one.

– See Appendix, for tips on staffing a crypto project

• Fairly simple to positive test crypto. How will your “brilliant programmer” negatively test it?

SNAKE OIL CASE STUDY

Commercial ASP provider

– Vendor one-way hash

Asserted irreversisble

– Proprietary algorithm for protecting privacy data


protecting privacy data (Social Security Numbers)

– Permutation cipher with algebraic transforms

– Programmer held a Physics PhD

See Appendix for tips on avoiding Snake Oil

SNAKE OIL CASE STUDY:

PERMUTATION CIPHER AS HASH


f1: A' = INT(ABS(mod( B + (A2 –A) , 10)))

f2: B' = INT(ABS(mod( (A*C2*D2) - C , 10))))

f3: C' = INT(ABS(mod( √B*(B3-(C2 /A)) , 10)))

f4: D' = INT(ABS(mod( A-7 , 10)))

etc.

*Algorithm simplified for clarity... but not by much...

SNAKE OIL CASE STUDY:

TOO CLEVER BY HALF

• Bad crypto: Cracked in 20 minutes using Excel

• Mod 10 ensured it was easy to break

• Perfect algebraic plug-n-chug formula

• Easily reversible, so not “hash”

• Only protection was secret of the algorithm


• Only protection was secret of the algorithm

• It looked smart and complex - It wasn’t.

• He was in over his head

• Instant reaction by Paul Kocher:

“Why didn’t he just use SHA-1?”

CASE STUDY: SOFTWARE KEY PROTECTION

• Long ago in a company far, far away...

• We needed to protect data at rest: Column-level database encryption

• Artificially constrained in use of tools:


• Artificially constrained in use of tools: Embedded crypto functions in a major database engine

CASE STUDY:SOFTWARE KEY PROTECTION

What we found in the database crypto lib:

• Implemented FIPS 46–DES in ECB only

ECB


• No protection against weak keys

• No PRNG, seed generation, LFSRs

• No ability to securely erase keys/sub-keys

ECB


What we found:

• Key protection method = Caesar cipher

• No key management functions

• Difficult to use non-alpha keys


• Difficult to use non-alpha keys– Assumption of keyspace was passphrase

– “PASSWORD”, “FOOTBALL”, etc.

• No support to provide safe cipher or key handling (e.g. avoid delimeters)


What we found:

• No salt or seed support without hand-rolling

• Only hash available was SHA (not SHA-1)

• No X.509 support (RSA, Diffie-Hellman/DSS...)


• No X.509 support (RSA, Diffie-Hellman/DSS...)

• Very poorly documented – Largely by sample code

– OK, by _bad_ sample code


HoweverD

• Sample code didn’t address inherent flaws

• Sample code encouraged poor crypto practices

– Several weaknesses in sample code


– Keys of “ALEXALEX” and “SECURITY”

– Search engine found wide use of sample code

• Apparent broad implementation of insecure sample code

• Developers were posting their PRODUCTION crypto implementations, with inherent weaknesses!

– Touted by vendor as strong cryptography

CASE STUDY RESULT

• Hired cryptographic implementer & cryptanalyst

– Short-term engagement

– Develop, certify & implement the code

• Copious documentation and testing

• Labor costs more than buying a proper crypto engine.


• Shared findings with vendor, who published some developer notes and changed their documentation

– but didn’t fix their crypto, and left the bad sample code intact

33

APPLICATION

1. Management needs to hear about key management, not cryptography

2. Focus on capabilities, implementation, documentation & processes, not products and protocols

3. Layered controls mean more than key space


4. Use risk analysis to determine when to bring in the cryptographic hired guns

APPLICATION

5. Custom cryptosystems should be certified commensurate with risk

6. Avoid vendor snake oil

7. Test cryptographic operational functions

8. Train your admins on key functions & key protection


8. Train your admins on key functions & key protection

Q & A

Surely, there are questions???


LOGISTICS

Please fill out evaluation forms

Contact information:


Dan Houser

Note: All graphics used in this presentation, unless otherwise noted, are believed to be in the public domain.

AppendixOr, how to fit 3 hours of material into


Or, how to fit 3 hours of material into 60 minutes of time…

38

APPENDIX

� Fragility of cryptography

� Identity & cryptography

� Stupid Developer Tricks

� Case Study: Death by Audit

� SSH – as many issues as SSL

� How to hire & staff a crypto project


� How to hire & staff a crypto project

� Detecting vendor snake oil

� Why self-signed certs are evil

� How good people buy bad crypto

CRYPTO DOESN'T ERODE, IT IMPLODES

• Engineering for key length focuses on:

– Brute force work required

– Moore's Law

• However, cryptosystems don't erode, they collapse catastrophically

• Remember, brute force is last resort


• Remember, brute force is last resort

• Moore’s Law provides the OUTER limit of the key life, not the INNER bound.

CRYPTO DOESN'T ERODE, IT IMPLODES

• So, why do we establish life of keys based on Moore's Law? Because it's easy. It's also wrong.

• Shouldn't the life of the cryptosystem be based on risk management?


Risk = Vulnerability * Threat * Asset Valuation

CRYPTO IS ABOUT IDENTITY

• Almost all crypto addresses identity management issues...

– Who are you?

– How do I know you are authentically you?

– Who can access this file?

– Who can encrypt or decrypt this file?

– Has an unauthorized change occurred?


– Has an unauthorized change occurred?

– Did this really come from you?

– Are you authorized to access keys?

– Are you authorized to change keys?

CRYPTO IS ABOUT IDENTITY

Without solid identity management, you can't implement solid cryptography

Example: Sending OTP tokens through US Mail that were


Example: Sending OTP tokens through US Mail that were requested by a Hotmail account user. Great crypto, built on a lousy identity registration process, creates a flawed sense of security.

To address cryptography problems, you must often first address identity problems.

SEGREGATION OF DUTIES IS ROUGH

• Very difficult to achieve operationally without significant risk.

• “Hit by a bus” “Hit the lottery” issue

• Operational crypto teams often with:

– Root/ administrator for their servers


– Root/ administrator for their servers

– Keymaster administrative account

– Sensitive data access

– Ability to substitute or pervert data streams

• Segregation of duties would turn 3 people into 14 and dramatically reduce productivity.

MOST OF OUR KEYS ARE DICTIONARY WORDS

...or are protected by dictionary passwords.

– Laptop encryption

– Windows EFS

– PGP keys

– Unix/Windows passwords


– Unix/Windows passwords

– Service execution passwords

– Sample code dropped into your source code

– Password-protected encrypted USB

– MANY keys are stored on file shares

KEYS PROTECTED BY DICTIONARY WORDS

�Often keys and/or protecting passwords are dictionary words in practice

�English has high entropy

– 0.8 bits per byte

– 10 character passwords provide 8 bits of entropy ≅ 8 BIT CRYPTO

�Far easier to guess and brute force


�Far easier to guess and brute force

�Theoretical vs. actual strength

� Japanese entropy is much higher than English, at 4.30

� Still, 8-character DES key in Japanese ≅ 34 bits, not 64

�Lesson: Don’t confuse key space with password space

STUPID DEVELOPER TRICKS

You will likely find these same practices in your source code. I have!

• Super Decoder Ring protection for keys in source code or storage: ROT13, big-endian, bit shift, static XOR, Caesar cipher, Base-64, XOR-shift

• Search code for key=“ seed=“ IV=“


• Search code for key=“ seed=“ IV=“

• Search code for “hidden”

• Use of static keys that never change

• Keys on file share

CASE STUDY: DEATH BY AUDIT

• Mainframe application protected by RACF

• Audit finding: system doesn’t detect similar passwords (e.g. Smith001, Smith002D)

• Auditors required system to detect substantially similar passwords at reset


• Solution – symmetric encryption of passwords in storage, instead of RACF


Brilliant programmers used this scheme:

(Password) XOR (Password Last Chg Date)

Note! Not DateTime, Date


Stored in database:

Encrypted Pwd, Password Last Chg Date

Set passwords for 30 day expiry


Result:

• No salt – moved from salted hash to this

• Only 30 possible values for the key

• In practice, only 22 values to try!!

• Keys stored with ciphertext - horrible!


• Keys stored with ciphertext - horrible!

• Moved from supported commercial system to total hack-job

MORE STUPID DEVELOPER TRICKS

Using MS-CAPI, Java Crypto lib, C++ crypto without training and scientific rigor

Developers should NEVER do crypto

I suggest instead that developers make calls to centralized functions developed (and vetted by) cryptographic


functions developed (and vetted by) cryptographic developers:

Encrypt {Type=SSN}{Data=xxxxxxxxx}

Let centralized policy make the decisions

Returns {KeyIndexValue}{Method}{Ciphertext}

IS IT USING SSH?

• Regulations encouraged encrypted connections.

• In the US, intense pressure for Sarbanes-Oxley compliance by SEC used by audit firms to force project teams into broad application of encrypted connections.


• As a result, auditors learned to ask the questionD

Is it using SSH?

SSH HAS A FUNDAMENTAL WEAKNESS

SSH is a GREAT protocol, but...

– Key management is required

– In an enterprise, distributing digital certificates to all SSH servers and clients can be difficult

– In practice, SysAdmins often too lazy to validate SSH keys


– If SSH keys fingerprints aren't validated, then man-in-the middle attacks and spoofing can be used to grab admin passwords.

– You should require admins to distribute and keep a log of validated hashes.

• rfc4344 on SSH Security Modes recommends rekeying SSH after

1Gb data

• Does your secure file transfer facility transfer large files?

• If so, do they rekey SSH after every 1Gb transfer?

• Host keys commonly stored on networked shares by SSH clients, so

open to tampering

IS IT USING SSH?


open to tampering

• Configuration controls are on the client

• SSH Protocol can ignore authentication:

The protocol provides the option that the server name - host key association is not checked when connecting to the host for the first time. rfc4251

• As with SSL, cleartext is a valid mode.

• SSH & SSL both let you make up your own crypto algorithms on

the fly:

Anyone can define additional algorithms or methods by using names in the format name@domainname, e.g., "[email protected]". -rfc4251

IS IT USING SSH?


Lessons: As with SSL focus on:

– Key management

– Training

– Implementation of controls

– Documentation

ENGAGING A CRYPTOGRAPHER

• What are you trying to achieve?

– Building a secure cryptosystem

– Vetting/Certifying a cryptosystem

– Breaking the cryptosystem

– Implementing COTS cryptography


– Implementing COTS cryptography

ENGAGING A CRYPTOGRAPHER

• Know what you need

– Cryptographer

– Cryptanalyst

– Cryptologist

– Cryptographic Implementer


– Cryptographic Implementer

– Cryptographic Programmer

USE MORE THAN ONE

Seed values / PRNG Cryptographer

Cryptographic

Example: PCI Database encryption project


Key Mgmt System

Database

programming

Cryptographic

Implementer

Cryptographic

Programmer

WRAP THE ENGAGEMENT

Crypto Savvy Security Architect / Engineer

Cryptographic Implementer

Cryptographer Security

Savvy


Cryptographic Programmer

Savvy

Project

Mgr

Crypto Savvy Risk/Certification Analyst

CRYPTOGRAPHERS AREN'T CHEAP

– Segregate the work to permit each expert to do the job they do best

– Use Security Engineer for “grunt-work”• Project management tasks

• Requirements gathering

• Managing the deliverables carefully


• Managing the deliverables carefully

• Engaging/managing cryptographic experts

• Documentation, meetings, logistics

• Performing due diligence on scope & requirements

• Governance cycles & review

USERS DON’T CARE ABOUT CRYPTO

Why? We tell them not to care, every day in Dev, Test & QA environments, by using self-signed certificates:


SELF-SIGNED CERTS ARE EVIL

• Why do we use self-signed certificates on our Intranet sites?

– Cheap, economical, easy

– “It's just test”

• Result: Users are trained to ignore security

• In testing 99+% of users will click-through certificate failure error messages in PROD


error messages in PROD

• Same issues with domain changes producing stale certificate warnings

SNAKE OIL DANGER SIGNS

“We have this brilliant guy”

Secret algorithms

“It’s just standard 3DES using standard Java”

New cryptography

...think “new drugs”, not “new car”


...think “new drugs”, not “new car”

Won't disclose details, despite NDA and Star Chamber meeting.

Not certified by a cryptographer


Name dropping - “The DoD uses it!”

Security experts, rave reviews, celebrity / industry endorsements

Technobabble obfuscation – the half-modulo perfect forward secrecy inverse hashinator.


perfect forward secrecy inverse hashinator.

“Trust us”

Claims of Infinite keyspace / perfect security

Revolutionary new concept

“Military Grade” cipher


Recoverable keys

Our is better, because theirs is insecure

Provably secure using One Time Pad

Bolt-on crypto added as a COTS feature

More emphasis on GUI than crypto


More emphasis on GUI than crypto

Foolproof products

Crypto vendors who don't understand key crypto concepts (even their SMEs)

WHY DO PEOPLE BUY BAD CRYPTO?

• Regulatory pressure is pushing us in the wrong direction to check the box �

• “Project ABC will implement Cryptonite 7.1”

– instead of fixing a business problem, states implementation of a product as its own means to an end

– Loss of focus on the need to fix a business problem


– Loss of focus on the need to fix a business problem

• Check the box, problem solved, we're done

• However, have we improved our capabilities?

PEOPLE BUY BAD CRYPTO

• Built on a shaky foundation

• Have you solved or moved the problem?

• Instead, we should:

– Focus on building capabilities


– Focus on building capabilities

– Start with the basics: Key management, cryptographic use policies, information classification, identity management, cryptographic governance, crypto team

secure development deploying crypto in the real worldaz9194.vo.msecnd.net/pdfs/110902/3382.pdf ·...

Documents