Case Study: Leveraging TPM for Authentication and Key Security

(1)

Case Study: Leveraging TPM for

Authentication and Key Security

Gautam Muralidharan

Manager, Advisory Services

PwC

(2)

Speaker Introduction

Gautam is a manager in the Advisory Technology practice

at PwC. Gautam has 8 years of experience designing,

developing, and implementing complex Identity and Access

Management (IAM) systems. Gautam brings in-depth

knowledge and experience in security architecture,

development tools, and IAM software packages. He has

combined those experiences with the latest technologies to

design and implement scalable Sign-On solutions, user

management and authentication/ authorization systems

across mixed platform environments. He is currently

serving as the chief-of-staff to the US Advisory Security

Leader for PwC.

[email protected]

612-306-0281

(3)

PwC Advisory Security Services

Our Information Security Solutions help IT leaders and decision-makers integrate information

security into strategic decision-making processes across the enterprise in order to better drive

business performance, manage risk, and increase shareholder value.

–

4,700

professionals in

North America

–

8,000

professionals in

EMEA

–

3,900

professionals in

Asia Pacific

–

850 professionals providing services in matters related to security and risk to

geographies outside of North American, EMEA, and Asia Pac

PwC’s professional services are delivered to clients by a workforce of over

150,000 employees and partners in 850 locations spread across 142

countries. Primary Lines of Service include Audit, Assurance and Business

Advisory Services, Global Tax Services, Business Process Outsourcing,

Corporate Finance and Recovery Services, and Human Resource Services.

Also composing PwC are Internal Firm Services organizations, which include

Finance, internal Human Resources, Infrastructure and Information

Technology (IT). The PwC IT organization provides internal IT services to

the Firm.

For further information visit our web site at:

(4)

Agenda

• Our Journey

• Considerations and Lessons learned

• Questions

(5)

(6)

What do we use PKI for

• WiFi access (PKI based authentication and

tunneling)

• VPN access (identification and authentication)

• LAN access (IEEE802.1x pre-authentication)

• Aura (P2P sync, data transport encryption,

authentication).

• Code signing (trusted applications).

• Internet Explorer webpages working with Digital

Certificates

• Any other usage when you need more security than

a simple Global ID+password.

(7)

Risks we considered with our current

solution

• You have created the key pair.

• You have fulfilled a process to convince

others that it is you they are

communicating with (Identity Proofing).

• All this, only because you are the owner of

the Private Key and the accompanying

Digital Certificate.

• But what happens if you are not the sole

owner of the Private Key anymore, e.g.

your Private Key is stolen or copied by

me?

• Then I can impersonate you!

• So what?

E.g. your colleague wants to exchange an

Aura client file and searches on the

network for “You” to setup a peer-to-peer

connection. Your name pops up (actually it

is me with your Private Key). He trust this

and start sending me the sensitive client

file.

(8)

Risks we considered with our current

solution

• The Private Key is stored on hard disk and is protected by the CSP.

• “Jailbreak” is software that can steal a Private Key. The Public Key is

already public so the key pair can be used by others!

• E.g. a stolen Private Key and certificate on a Debian (Linux) PC

running a VPN to PwC and having a Remote Desktop Connection to

a PwC Windows server :

(9)

We wanted to move to a more secure

alternative

• This is not what we want to read in the morning papers.

• So, the Private Key must be protected at all times!

• But, in the current situation the Private Key cannot be

protected because it is stored by software (on the hard

disk).

• Even when the Jaibreak exploit is repaired it could be

possible that there will be other exploits.

• The solution preventing the theft of Private Keys? Store

Private Keys in tamper resistant hardware!

• But, cryptographic hardware is expensive and hard to

maintain.

• And, usually you have to buy proprietary (expensive)

hardware which does comply to certain standards only.

(10)

Solutions we considered and challenges

• USB dongles:

–

Additional hardware costs

–

No open software standard

–

Lost/Stolen management overhead

–

Reluctance of business to have additional device

• Smartcard (SIM, USB or proximity):

–

Additional Hardware required

–

Expensive

–

No open standard

–

Additional provisioning requirements

–

Additional management costs

–

Lost/Stolen management overhead

–

Reluctance of business to have additional device

–

Not centrally managed

• Trusted Platform Module (TPM):

–

Possible changes to PwC certificate management

application required depending on architecture

design.

–

Requires additional laptop/desktop

provisioning/lifecycle management processes

–

Tied to single machine

(11)

Why we picked TPM

• Already in 95+% of our laptops

• Is based on open standards

• Gives FIPS 140-2 protection

• Can be centrally or locally managed

• Cheap (no hardware costs)

• Protects against ”Jailbreak” and similar tools

• Delivers additional secure cryptographic functions

(trusted startup, random number generator, digital

signature etc.)

• Minor changes in PC Lifecycle Management. TPM setup

in a few minutes

• Our applications worked well with TPM often with

minimal to no code change

(12)

TPM implementation

• Example: VPN Multifactor Authentication with TPM

• When you want to connect to the PwC network through VPN,

you need a:

1. Digital Certificate and Private Key (1

st

_{factor, “have”)}

2. GUID and GUID password (2

nd

_{factor, “know”)}

• No changes to the infrastructure when using the TPM and no

Jailbreak vulnerability anymore!

(13)

(14)

Phased approach to implement

multi-factor authentication solutions

14

Collect

Requirements

Develop detailed

business and

technical

requirements

Solution &

Vendor

Selection

Develop RFP

based on

requirements

and select

vendor

Execute

Pilot

Facilitate pilot

with a small

subset of

users to

determine

solution

suitability

Design &

Implementation

Integrate of the

solution into

environment

Solution

Rollout &

Ongoing

Operations

Solution roll-out

across enterprise

and knowledge

transfer to

operational

resources

(15)

Key steps in a Multi Factor Authentication

deployment

• Determine requirements for two-factor authentication from key stakeholders

• Conduct a current state ("as-is") analysis of two-factor authentication and

supporting processes

• Design future state of multi-factor authentication along with supporting

processes. Solution design will take into account multiple user communities

including service accounts, administrators, contractors etc.

• Select a flexible and scalable vendor solution that supports requirements

• Integrate solution management with existing Identity management system

• Ensure that the selected solution is compliant with relevant legal and

regulatory requirements

• Develop end user deployment strategy, including change management and

communication.

• Provide detailed and comprehensive framework to support operational

process components (i.e. issuing cards, lost cards, training, policy and

procedures, etc)

• Develop documentation to support rapid solution integration at other

businesses

(16)

Ask these questions

– Is the solution currently supported in organizations operating in multiple

countries/regions?

– Are other large conglomerates/industry peers using this vendor?

– Is the solution scalable?

– What are the impacts to user experience if this solution is deployed?

– Is the registration process implicit, transparent, history based or explicit/formal?

– What are the additional hardware/software (smart card readers/GINA

modifications/CSP additions) requirements for a functioning solution in your

environment (Windows/Unix)?

– What is lost/stolen cards/token process?

– How is the authenticating information stored on the token/smart card (plain

text/encrypted)? How are the end-user private keys protected

(pin/password/biometric)?

– Has the solution been integrated for provisioning with an Identity management

solution? What is the extent of integration (automated, notification based)

– What application integration methods (e.g. API, redirect/filter, agent, etc.) are

supported?

16

Busi

ness

Te

ch

no

lo

gy

(17)

Lessons Learned

Areas of Concern

Critical Success Factors

Project/

Program

Structure and

Approach

• Project led by technology group without high-level partnership with the business

• No business executive sponsorship

• Failure to understand enterprise nature of multi-factor authentication solutions

• ‘Boil the ocean’ scope and approach – ‘big losses’ vs. ‘quick wins’

• Failure to set realistic expectations

• Active high-level business executive sponsorship • Clear project/program charter defined

• Clear definition of roles and responsibilities • Agreed upon guiding principles and objectives • Short-term, mid-term and long-term milestones

• Dependencies and inter-dependencies well understood • Broadly accepted success criteria

Organization

and People

• The processes, technology and people span across multiple geographies, business units and functional areas – priorities, objectives and agendas aren’t always aligned

• Lack of resources and experience to adequately build and maintain solution

• Operational impact is not fully contemplated during planning and design phases – technical and end user

• Business and IT ownership/sponsorship

• Communications and change management integration within program

• Define roles and responsibilities – entire lifecycle • Training – technical, functional and end users

Process and

Data

• Lack of documented understanding of current and future state processes

• Regulatory and compliance risks – over or under controlled

• Data management challenges – what to protect? How much to protect?

• Document and maintain current process workflows • Develop new process use cases before project

requirements

• Address data issues first

Technology

• Product selection is ‘the strategy’

• Rushing to implement product before business requirements

are defined

• Buying into vendor rhetoric – it’s not simple • Poor understanding of the scale and impact of the

technology

• Select solutions after business requirement and processes are defined and accepted