370 likes | 603 Views
Strong and Alternative Authentication. Rafal Lukawiecki Strategic Consultant, Project Botticelli Ltd rafal@projectbotticelli.co.uk www.projectbotticelli.co.uk.
E N D
Strong and Alternative Authentication Rafal Lukawiecki Strategic Consultant, Project Botticelli Ltd rafal@projectbotticelli.co.uk www.projectbotticelli.co.uk Copyright 2006 © Microsoft Corp & Project Botticelli Ltd. E&OE. For informational purposes only. No warranties of any kind are made and you have to verify all information before relying on it. You can re-use this presentation as long as you read, agree, and follow the guidelines described in the “Comments” field in File/Properties. This presentation is based on work of many authors from Microsoft, Oxford Computer Group and other companies. Please see the “Introductions” presentation for acknowledgments.
Objectives • Revisit the foundation of IAM from the perspective of modern, strong and specialised authentication mechanisms • Explain ways of integrating them within a Microsoft framework containing heterogeneous systems • Highlight some remaining issues and opportunities
Session Agenda • Public Key Infrastructure • Smartcards and MCLMS • OTPs and RSA SecurID • Biometrics
Microsoft’s Identity Management Identity Lifecycle Management Access Management Directory (Store) Services Identity Integration Server Active Directory & ADAM Active Directory Federation Services BizTalk Extended Directory Services Authorization Manager Audit Collection Services PKI / CA Enterprise Single Sign On Services for Unix / Services for Netware ISA Server SQL Server Reporting
PKI • Infrastructure for practical use of cryptographic mechanisms for authentication and authorisation purposes • Not new! Very well tested and based on sound principles. • Unfortunately, too complex from a today’s typical user’s perspective
Strong Authentication • Unlike most password systems, PKI-based authentication relies on certificates and protocols that provide highest level of strength in terms of veracity of authentication • No secrets are exchanged in open • No reusable data is sent away • Man-in-the-middle is usually not possible • Scientific edge to understanding strength • Protection of private keys (associated with certificates) requires additional devices, and, perhaps, passwords
Microsoft Certificate Authority in Windows Server 2003 • Standards Supported: • RFC 2459 Support (CRLs and Certificate Profiles) • X.509 v3, v4 • RFC 2797 (CMC) • SCEP (Simple Certificate Enrollment Protocol) • PKCS #1,7,8,10,12 • RFCs 2311, 2312, 2313, 2527, 2587, 2631, 2632, 2632, 2633, 2634 • RFC 2560 (OCSP – Online Certificate Status Protocol) • Supports Auto enrollment, Client Certificate Distribution • Built into the OS, API/CLI/Web Interface
Windows as CA • Windows consumes and provides PKI and CA services • This is referred to as one of three“Extended Directory Services” in terms of IAM • The other two being: Smartcard Management and Information Rights Management • Apart from replacing passwords, this leads to a very powerful form of Single Sign-On • Interoperability depends on mutual recognition of CA roots and certificate claims
Modular Architecture • Windows OS uses multiple, user-selectable, Cryptographic Services Providers (CSPs) to implement core functionality, such as encryption etc. • Communication with CSPs is achieved through a number of APIs, of which the most fundamental is CryptoAPI (CAPI, CAPICOM) • CSPs vary widely, which can compromise security • Microsoft has recently (Dec 05) shipped a generic CSP that can be used where custom ones are not economical • If this is of interest to you, please review significant new mechanisms and APIs in Windows Vista
Cryptography Recommendation • At present (December 2005), consider using the following cryptographic mechanisms available in Windows in preference to others: • AES-128 (or AES-192, or AES-256) • RSA 2048 (or longer) • “SHA-2” (i.e. SHA-256, or SHA-512) • DSA • Avoid the following, if possible: • 3DES (speed) • RC2 (superseded but generally fine) • RC4 (issues, but can be overcome) • DESX (esoteric) • Do not use at all: • DES (strength)
Cryptography Tomorrow • US NSA and NIST recommendation as of Feb 2005 is to implement “Suite-B” protocols • This is very rarely done in today’s software • Good news: Microsoft announced support for Suite-B in Windows Vista (and Longhorn Server) • For all internal implementations Microsoft will not use weaker algorithms than Suite-B • But, of course, they will support your choice to do so if you wish
Smartcards/Tokens and Certificate Lifecycle Management Server
Why Smartcards? • Smartcards are physical devices that protect a private cryptographic key from being copied or used without additional authentication • Can add other functions, such as work photo-IDs, door RFID keys etc. • Basically: • Do not store a private key on the computer itself if possible • If you do, ensure it is well protected, e.g. using Windows default Protected Storage service, DPAPI etc.
Form Factors • Smartcards are not always “cards”, so they are sometimes referred to as Tokens • USB devices • Bluetooth devices • Incl.: Mobile Phones • Active RFIDs (Radio Frequency Identifiers) • On-board silicone chips, sometimes being part of other chips (Trusted Platform Modules, such as TPM v1.2) • Note: this is a future direction being adopted by forms of “Trusted Computing Group’s Base/Infrastructure”
Secondary Authentication(Optional) • Smartcards usually do not provide their services, or any access to the private key, unless a secondary authentication succeeds: • PINs and passwords • Not sent across networks, this is locally processed on board of the card • Biometrics (see later) • Co-presence of other devices • RFIDs • Note: the authenticator may be on board of the “card” reader (more secure), or may be a function of the PC or host computer (less secure or less trustworthy)
Smartcard Compatibility with Windows • Entirely dependent on the presence of a suitable CSP (Cryptographic Service Provider) • Typically installed when hardware “reader” device is installed • Many providers exist • Microsoft promotes a .NET-based smartcard through Axalto consortium • Windows Vista allows a broader range of smartcards to be supported, including: • Card Communication Modules • Common CSPs, KSP (Key Storage Providers) • CNG (Open Cryptographic Interface for Windows)
Word About Smartcards • Some smartcards are “dumb”, i.e. they are only a memory chip, so key can be easily stolen • Not recommended, not approved to Common Criteria (FIPS-140-2) • Not all smartcards are equal • Not all have an on-board RNG (Random Number Generator) • Some cannot generate keys and rely on the reader or the host • Self-destruct is possible on some • Recommendation: • Good smartcard should contain its own CPU (co-processor) as powerful as affordable, protected memory, specialised CSP, is CC certified
Microsoft Certificate Lifecycle Management Server (MCLMS) • Users will, of course, lose smartcards • They will expire • Need for: • Provisioning, maintenance etc. • Lifecycle management of smartcards has not been a function of Windows, but is implemented by the Certificate Lifecycle Management Server • Based on Alacris idNexus which has been acquired by Microsoft in Sept 2005
CLMSIdentity Assurance Management System • Integrates with: • Windows 2003 PKI • Entrust (CA) • Supports: • Lifecycle Management (incl. Provisioning) • Smartcard Logon • OCSP through Identity Validation System • Client and server for Online Certificate Status Protocol • Used by IIS, IE, Outlook and many others • Common Criteria certified
One Time Passwords (OTPs) • Usually: hardware that generates a single-use value that functions as a password • Trust between the device and the remote system is implemented as physical relationship • E.g. precise clock synchronisation, as in RSA SecurID • As with smartcards, secondary authentication is possible (PIN, biometrics etc.) • OTP devices are frequently called Security Tokens, or Tokens • A bit confusing, as some smartcards are also known as tokens, e.g. Aladdin Token)
OTP or Smartcard? • Effective functionality and security strengths are surprisingly similar, however: • Ease of initial deployment: • OTPs have an advantage, as most smartcard systems require presence of PKI first • Extensibility • Both are similar, though OTPs have an incremental cost for each additional system being interconnected • Universal Integration • Smartcards and PKI, being based on standards, tend to have a more universal appeal (as long as PKI is compatible, which usually is the case) than OTPs
RSA SecurID • Probably the best known OTP system • Like most OTPs, it functions as a client-based Single Sign-On system • Requires additional servers/services • Integrates very well with Microsoft IAM • Unlike smartcards, requires no readers • With web-based thin-client applications, even no additional client software is needed
Client SSO Access Gateway Client SSOs in IAM Novell User Remote Access Strong Authentication UNIX/Linux User Windows User Remote Windows User Browser User Web-Admin Integration Intranet Access Extr. Directory Remote Access DMZ Central Role Management Account Management Console Smard Card Management Central Web Authentication Central PW-Reset Central Web Policy Management Central Directory & Yellow Pages Central Self-Service Web SSO Fed. SSO Desktop SSO Auditing & Reporting Service Registry Services S S S S S Workflow S S Infrastructure Directory S S S Provisioning S S S Synchronization PKI, eID, DS Backend SSO IPSec, Netw.-Sec. Process Integration Password Synch. ERP UNIX Sun Linux DB2 HOST Mail RAS Oracle SQL Novell XYZ
RSA SecurID in Microsoft IAM UNIX/Linux User Remote Access RSA Strong Authentication SecurID Windows User Remote Windows User Browser User Web-Admin Quest + Centrify RSA Sign-On Manager Intranet Access ADAM RSA ClearTrust ISA DMZ Central Role Management, 3rd Party WebAdmin, 3rd Party Alacris Sharepoint ++ MIIS + MOM Kerberos + AD Groups ADFS + AzMan Active Directory (+ADAM, +UDDI) Sharepoint 3rd Party SQL Server Rep. Tools SQL Server, ACS, MIIS ADAM / AD / UDDI Services S S S S S BizTalk S S AD S S S MIIS S S S MIIS Windows Server PKI/IPSec + Active Directory Windows CA or Keon ESSO BizTalk MIIS ERP UNIX Sun Linux DB2 HOST Mail RAS Oracle SQL Novell XYZ
Biometrics • Identification (rather than authentication) of a human subject by means of scanning their physical characteristics, such as: • Image (face, iris, retina, hands, papillary lines) • Sound (voice print identification, footsteps) • Movement (writing characteristics, facial ticks) • Chemical (body odour, breath, hair composition, possibly even DNA analysis) • Physiology (pulse, blood pressure, temperature, blood oxygen content, intraoccular fluid pressure) • These are typically secondary verifiers to avoid inanimate objects being used to fool the scanner
Biometrics • Generally, an over-hyped area: be careful and sceptical • Useful as a secondary protection of a private key on a smartcard in a controlled environment • Advantage: • Simple and works in some environs, e.g. immigration • Weakness: • Not useful for at-home, remote etc. applications as no way to ensure it is your real fingerprint, iris, retina etc. being scanned • Biometric data can be stolen and can be used to fake identity – no way to change it later • Still many positive and negative false matches
Controlled EnvironmentsPresence of a Trusted Observer – Guard, Officer, Witness… • Trustworthiness of biometrics relies on the trust in the scanner/reader and trust in the correct application of the scan procedure • Scanner Trust: • There must be no easy way of “replaying” the biometric sequence, bypassing the device • In reality, this means device must have construction that cannot be easily compromised, and must have a pre-arranged, trusted and confidential connection to the Relying Party • Today, this requires a controlled environment • Procedure Trust: • Ensuring that it is a real fingerprint/iris/retina being scanned, rather than a replica
Meaningless Application • Example: • Using a keyboard-based fingerprint scanner to allow a home user to log into an online banking site • Problems: • Copies of fingerprints will be readily available on the keyboard. • What if the keyboard is stolen? • What if someone breaks into the room and uses your keyboard? • How does the bank know it is really a finger being scanned? • Future: • Perhaps devices will exist that can overcome these issues, but that is not likely to happen very soon
False Negatives/Positives • Today’s biometrics still suffers from a large pool of false matches • According to UK Home Office 2005 research, it would be necessary to scan one iris/retina and fingers of both hands to reduce the mismatches to an acceptable level • Future? Very bright, as we overcome this problem.
Role of Biometrics • Biometrics is very useful in the following situations: • Secondary authentication for a smartcard or a token/OTP device • Primary identification in controlled environments • Primary authentication for low-security applications in non-controlled environments • But that is not strong authentication
Summary • Strong authentication removes the need for user-managed passwords • Most today’s solutions are based either on smartcards or OTP tokens, and require some client-specific integration • Biometrics is an interesting enhancement of identification and, perhaps, authentication but has limited applications at present www.microsoft.com/idm & www.microsoft.com/itsshowtime & www.microsoft.com/technet
Special ThanksThis seminar was prepared with the help of: • Oxford Computer Group Ltd • Expertise in Identity and Access Management (Microsoft Partner) • IT Service Delivery and Training • www.oxfordcomputergroup.com • Microsoft, with special thanks to: • Daniel Meyer – thanks for many slides • Steven Adler, Ronny Bjones, Olga Londer – planning and reviewing • Philippe Lemmens, Detlef Eckert – Sponsorship • Bas Paumen & NGN - feedback
Q&APlease complete evaluation forms when you receive them – thank you.Read more about IAM at: www.microsoft.com/idmWatch other seminars at: www.microsoft.com/itsshowtimeFind all IT Pro technical information at: www.microsoft.com/technet