Crypto in the Real World: or How to Scare an IT Auditor

Copyright © 2010 Daniel D. Houser
Insert presenter logo
here on slide master
Crypto in the real world
…. Or how to scare an it auditor
Dan Houser, CISSP-ISSAP CISA CISM CGEIT
Member, (ISC)² Board of Directors
Security & Identity Architect, Cardinal
Health
Session ID: AND-206

•
Cardinal Health, Inc. is a Fortune 17 company that
improves the cost-effectiveness of health care. As the
business behind health care, Cardinal Health helps
pharmacies, hospitals and ambulatory care sites focus
on patient care while reducing costs, improving efficiency
and quality, and increasing profitability.
•
More than 30,000 people worldwide.
•
$100 Billion Revenue
•
360+ facilities in 90 countries
Cardinal Health... Not a hospital

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
burned by cryptography. Hire an expert.
•
Do-it-yourself Crypto is as advisable as self-surgery
•
The 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
•
Case studies, real cryptography & cryptanalysis
efforts, and what gaps in design principles led to
compromises
•
Pragmatic view of cryptography

Cryptography is Math
•
Pretty formulas
•
Theoretical, Logical
•
Sound premises lead to proof after proof
•
Unassailable conclusions on paper
•
Digital
•
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
•
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
•
People issues
•
Balancing act
•
Imperfect measures
$
Security
Expense
Total cost
SCMM
Loss

Cynic’s View of
Corporate Cryptography in Context
Perfect math…
– 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,
– on run-away projects to achieve…
– 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
•
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?
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
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_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
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
Is it using SSL?

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:
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
Is it using SSL?

By default, TLS must support CipherSuite:
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
However, your server admins or developers may have
implemented:
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??
Is it using SSL?

Better Questions
q What business problem are you trying to solve?
q What are you protecting/information value?
q What is the threat model?
q What compensating controls do/could exist?
q How are you using SSH/SSL?
q What properties of cryptography are desired?
Confidentiality/ Integrity/ non-
repudiation
q What crypto modes & ciphers are you using?
q How are you creating, protecting & managing
keys through the entire lifecycle?
q What is the level of assurance needed/provided?
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 deadbolt 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
*nearly nobody...

Nobody Brute Forces Crypto
•
Cryptosystems fail due to implementation flaws
•
Brute force is too expensive
•
Only Intelligence services (e.g. NSA, GCHQ) &
Media Pirates use brute force
•
WEP – failed due to implementation, not RC4
•
CSS – failed implementation, cleartext key
•
Enigma – bad practices, poor key choice

Toolkits Matter. A Lot.
•
There are 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
protection using default language libraries
•
Use crypto toolkits such as Bouncy Castle, MS-
CAPI and RSA BSAFE

I have this hobby that gives me perspective…
21

Even great toolkits are dangerous
•
Easy to make mistakes constructing your own crypto
system, even with great tools… and exceedingly difficult
to test well.
•
Think Do-it-Yourself firearms @ 115,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 Kevlar vests
•
Pharmacists don’t design life-saving drugs
•
Truck drivers don’t design good bridges
•
Arsonists don’t design fire-proof buildings

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.
•
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 system – ASP/Cloud provider
– Vendor one-way hash
Asserted it could not be reversed
– Proprietary algorithm for 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
• Given “hash”, my 9 yr old solved for A,B,C,D,E...
• Perfectly reversible, so not “hash”
•
Only protection was secret of the algorithm
•
It looked smart and complex - It wasn’t.
•
He was in over his head
•
Instant reaction of a real cryptographer:
“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:
Embedded crypto functions in a major database
engine

Case Study:
What we found in the database crypto lib:
•
Implemented FIPS 46–DES in ECB only
•
No protection against weak keys
•
No PRNG, seed generation, LFSRs
•
No ability to securely erase keys/sub-keys

Case Study:
What we found:
•
Key protection method = Caesar cipher
•
No key management functions
•
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)

Case Study:
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...)
•
Very poorly documented – Largely by sample
code

Case Study:
However…
•
Sample code didn’t address inherent flaws
•
Sample code encouraged poor crypto practices
– Several weaknesses in sample code
– Keys of “LARRYLAR” 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 for short
engagement to vett and implement the code.
•
Copious documentation and testing
•
Had to spend more on labor to implement and run
manual key management than would have been spent
on a proper crypto engine.
•
Shared findings with vendor, who published some
developer notes and changed their documentation (but
left the bad sample code intact)
33

Summary
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

Summary
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

Q & A
Surely, there are questions???

Logistics
Please fill out evaluation forms
Contact information:
Dan Houser

Appendix
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
Ø 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
•
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?
– 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 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
– 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
– 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
Ø
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 “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, Smith002…)
•
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!
•
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
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
question…
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
• 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
Is it Using SSH?

• 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., "ourcipher-cbc@example.com". -rfc4251
Lessons: As with SSL focus on:
– Key management
– Training
– Implementation of controls
– Documentation
Is it Using SSH?

Engaging a Cryptographer
•
What are you trying to achieve?
– Building a secure cryptosystem
– Vetting/Certifying a cryptosystem
– Breaking the cryptosystem
– Implementing COTS cryptography

Use more than one
Seed values / PRNG
Key Mgmt System
Database
programming
Cryptographer
Cryptographic
Implementer
Cryptographic
Programmer
Example: PCI Database encryption project

Wrap the Engagement
Crypto Savvy Security Architect / Engineer
Cryptographic Implementer
Cryptographer
Cryptographic Programmer
Security
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
•
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
•
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”
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.
“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
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
•
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
– Start with the basics: Key management, cryptographic use
policies, information classification, identity management,
cryptographic governance, crypto team

Crypto in the Real World: or How to Scare an IT Auditor

Recommended

Recommended

More Related Content

Similar to Crypto in the Real World: or How to Scare an IT Auditor

Similar to Crypto in the Real World: or How to Scare an IT Auditor (20)

More from Dan Houser

More from Dan Houser (14)

Recently uploaded

Recently uploaded (20)

Crypto in the Real World: or How to Scare an IT Auditor

Editor's Notes