Why it s Time to Make the Change Analysis of Current Technologies for Multi-Factor Authentication in Active Directory

Transcription

1 GoldKey vs RSA Why it s Time to Make the Change Analysis of Current Technologies for Multi-Factor Authentication in Active Directory WideBand Corporation

2 Analysis of Current Technologies for Multi-Factor Authentication in Active Directory Introduction Many of today s large organizations rely on two-factor authentication. The principal motive for adopting multi-factor authentication is the large number of known attacks that have been made possible by the simple nature of the username and password model. The purpose of this paper is to provide a technology comparison between the GoldKey solution for multi-factor authentication into Microsoft Active Directory and the RSA SecurID solution. Special attention will be given to the strengths and weaknesses of these systems as they pertain to both the security provided and the expertise and effort required to deploy and administer them. Active Directory is Microsoft s implementation of an LDAP directory, and is the industry leader in central management for user accounts and permissions, as well as computer configuration within the enterprise. With their SecurID solution, RSA is currently the leading provider of OTP tokens. RSA SecurID Basics of OTP Tokens OTP tokens are often used to secure login to Active Directory, and are also widely used to provide twofactor authentication to VPN and web services. Initially, OTP tokens (either hardware or software) are assigned a serial number and are provisioned with a symmetric cryptographic key, also known as a seed, which will be used along with a time-based algorithm to generate the necessary passcodes. This algorithm converts the current time into a number of minutes since a predefined time (originally January 1, 1986), and cryptographically combines it with the token s seed to generate the OTP code [1]. The OTP codes are calculated independently by the tokens and a central appliance (called an Authentication Manager, or AM) during authentication, and compared at the AM to determine the status of the authentication. The initial seeding is done by RSA and customers receive their seed lists with the delivery of an order. GoldKey vs RSA Why it s Time to Make the Change 2

3 Prerequisites and AD Configuration The SecurID solution requires the presence of an AM for OTP code verification. The seed lists from RSA must be loaded into the AM by the customer, and the AM must be configured to use Active Directory as an LDAP Identity Source, which the AM will use to gather information about current users. This allows users and groups to be created within Active Directory as usual, and token mapping to be done within the AM Security Console. Other configuration options are available, but for Active Directory this provides the most straight-forward and maintainable solution from among the available options. Additionally, replica AM units may be configured to provide performance scalability and AM redundancy. This is often desirable since the AM maintains an internal database of user attributes not associated with Active Directory, such as the tokens that have been assigned and a SecurID PIN. In order to provide scalability and automatic redundancy, you must configure a load balancer to manage traffic destined for the AM units. Deployment After the prerequisites are in place, tokens must be assigned to the users who are to perform multifactor authentication. To accomplish this, a security administrator must log into the RSA Security Console, locate the correct user and link up a token by serial number (available tokens are listed from the seed list you imported previously). Then, care must to taken to make sure that assigned tokens are distributed to the correct users [2]. The last setup step is to provision the token. This is usually done by the user assigning a PIN to the token using the Self-Service Console after token distribution. Some user training is required in order for this process to be successful. Long-Term Deployment Considerations RSA SecurID tokens come with a sealed, unreplaceable battery, and are further preprogrammed with a lifetime specified at the factory. These tokens must be replaced at the end of their lifetime. Unless a user is willing to allow authentication traffic to traverse the internet, the number of required AM appliances will grow as the SecurID solution is deployed to multiple locations. GoldKey vs RSA Why it s Time to Make the Change 3

4 Authentication Once the tokens are provisioned and a user attempts to authenticate with the SecurID system, they are prompted for their username and passcode. A passcode is a concatenation of their PIN and the OTP that appears on their token. The username and passcode are then submitted to the Authentication Manager, which independently generates the correct passcode for the token assigned to the specified user [2] [3]. Figure 1. Signing into Active Directory with RSA SecurID If the passcode matches, the Authentication Manager returns the user s Active Directory password to the RSA authentication software, or agent, on the client s computer. The client then passes this information to the domain controller where it is checked with the Authentication Manager to confirm that a two-factor authentication has in fact occurred. GoldKey vs RSA Why it s Time to Make the Change 4

5 Security Considerations With this authentication model, it becomes obvious that the Authentication Manager must have access to a list of the seeds for the user s tokens, or a Master seed that can be used to derive the individual token seeds on demand. If an attacker were able to obtain the list of token seeds, or a Master seed used to derive token seeds, the security of this system could be compromised. See the Known Attacks section for more information. The SecurID solution relies on lists of symmetric keys that are generated by RSA and subsequently communicated to the customer. While this can be handled properly, it does not inherently preclude the accidental disclosure of that sensitive information. Security concerns that should be raised in this type of deployment include: 1. Are the seed lists, or the ability to derive these lists, retained by RSA? Since this information is retained by RSA, several valid questions should be considered: a. How well does RSA protect this information from unauthorized access? b. What constitutes authorized access, and does the customer have control of authorization? c. Since access to this information facilitates unauthorized access the customer s protected resources, should RSA, or any other third party, be trusted to make this decision? 2. How well protected are these lists in transit to the customer? 3. How well are the seed lists protected by the AM device itself? 4. Are seed lists retained by the customer, outside of the AM internal database? If they are: a. Are these lists stored in an encrypted form? b. How well are the encryption secrets protected? c. What measures are taken to ensure that even encrypted copies of these lists are protected from unauthorized access? Any security implementation that relies on a pre-shared key is only as secure as the means employed to store and distribute those keys. Generated seed files must be communicated to the customer securely, and then protected for the lifetime of the tokens. Known Attacks On March 17, 2011 the security of RSA s network was compromised and the seeds for a large number of SecurID tokens, or Master seeds used to derive these token seeds, were stolen [4] [5] [6]. In the following months, attacks against high-profile SecurID customers leveraged this information [4] [6]. GoldKey vs RSA Why it s Time to Make the Change 5

6 GoldKey Built-In Smart Card Basics of PKI and the GoldKey Solution In contrast to OTP solutions, PKI deployments utilize asymmetric encryption and digital signature using related keys. Instead of provisioning tokens and loading a list of seeds into a central appliance, unique secret keys called private keys are generated and loaded onto a GoldKey token. A particular public key can only be used for communicating with the individual that has access to the associated private key, and so can be freely distributed. For security, private keys are generated directly on the GoldKey device. GoldKey tokens include a built-in, PIV-compliant smart card and reader and provide an elegant integration with Microsoft's Active Directory and security infrastructure. GoldKey tokens allow a user to securely store and transport private keys for use within a PKI deployment, and have been widely adopted as a multi-factor authentication mechanism for Microsoft s Active Directory. GoldKey tokens are also often used for more than Active Directory authentication due to the wide range of possible uses for certificates. Common examples are authenticating to VPN and web services, digitally signing documents, and providing signing and encryption for secure communication. Prerequisites and AD Configuration The frameworks and management software required to deploy and manage a PKI solution are already built into Microsoft s operating system and Active Directory. As in other PKI solutions, the GoldKey deployment requires the existence of a root certificate authority (CA), and recommends that intermediate CAs also be deployed, allowing the root CA to remain offline, which is recommended in order to protect its private key. Once the CAs have been installed, the Smart Card User template should be duplicated and autoenrollment enabled for the new template. Enabling auto-enrollment requires a modification to the template and enabling a setting in group policy. Unlike all other Smart Card solutions, GoldKey is a fully integrated hardware solution for Microsoft Certificate Services. Deployment The deployment process consists of distributing a blank token to each user who will be required to perform multi-factor authentication. Once auto-enrollment has been enabled, users will be prompted GoldKey vs RSA Why it s Time to Make the Change 6

7 by Windows to obtain a certificate every time they log into their account until they have a valid certificate that can be used for authentication. Auto-enrollment can be enabled for all users or just users in a specific group. During the auto-enrollment process, the user will be prompted to insert their token and set a PIN. The heavy lifting involved in this process will be handled by the driver automatically installed by Windows for the GoldKey device. No central authentication appliance is required since GoldKey seamlessly integrates with the Microsoft Active Directory environment. When the process is finished, a key pair will have been generated directly on the token, and the certificate automatically signed by the Active Directory CA. This process takes place behind the scenes and does not require additional software on the user s machine. Long-Term Deployment Considerations The GoldKey solution uses a feature called auto-renewal to eliminate the labor and inconveniencies that arise from limited certificate lifetime. This process works very similarly to the auto-enrollment feature. When a user s certificate is getting ready to expire, they will be notified automatically by Windows that they need to enroll for a new certificate. The new certificate will be placed in an unused certificate slot, and the old certificate will remain in place. GoldKey tokens come with 24 available certificate slots. GoldKey tokens do not require batteries, and do not have a limited lifetime by contract or programming. Authentication When a user inserts their GoldKey token, the token is examined for valid certificates having the Smart Card Logon enhanced key usage, having a valid UPN, and having been signed by a trusted CA. If one is found, the user is prompted for their PIN. Once the user has entered their PIN, a message signed by the user s private key residing on the GoldKey will be sent to the Active Directory KDC (a component of the domain controller). The KDC then uses the certificate s UPN to find the user in Active Directory, and checks both the client s certificate and the validity of the signed message. If these steps are successful, the KDC responds with a signed message of its own indicating the user s login status, including an encrypted version of their Kerberos ticket-granting ticket (TGT) [7]. GoldKey vs RSA Why it s Time to Make the Change 7

8 Figure 2. Signing into Active Directory using a GoldKey Once the client s machine receives this message, the validity of the KDC s certificate and the signed message are validated. If everything checks out, the TGT is extracted from the KDC s response and used to obtain a service ticket to the local computer. This ticket is then used to log in to the client machine [8]. Security Considerations In order to have a secure PKI implementation, you must: Protect your users private keys. Avoid the use of broken hashing algorithms, such as SHA-1 and MD5. Use sufficient key sizes for RSA certificates (at least 2048), or use ECC certificates instead. Protect the root CA. This is usually accomplished by keeping it offline, unless you need to issue or revoke subordinate CA certificates. The physical device should also be kept in a locked facility under video surveillance. Protect your subordinate CAs by using strict physical access policies, proper firewall configuration, and regularly applying operating system security updates. Make sure that only authorized individuals are able to issue certificates. GoldKey tokens automatically protect a user s private keys due to the fact that keys are generated on the token itself and only the public key can ever be read from the token. This functionality has been verified as part of the FIPS validation of the token s components. GoldKey vs RSA Why it s Time to Make the Change 8

9 Key sizes and hashing algorithms are decided during CA creation and management, which is performed using Microsoft s configuration tools. The most difficult part of implementing a secure PKI solution is properly protecting the private keys for your root and subordinate CAs. However, this can be done well using the techniques described above and by incorporating HSM technology. Unlike alternative solutions available today, all of the components and processes described for GoldKey authentication to an Active Directory are already built into Microsoft s systems and security infrastructure. Known Attacks Various PKI implementations over the years have suffered from flaws that have led to improper certificate validation and consequently identity impersonation. Additionally, problems with the SHA-1 and MD5 hashing algorithms have allowed rouge CAs to be created [9] and duplicate certificates to be generated [10]. Use of more secure hashing algorithms is required in order to create a secure PKI deployment. Many other attacks have featured the theft of both corporate and individual certificates, underscoring how critical the secrecy of private keys is to the integrity of a PKI system. Solution Comparison Deployment, Administration, and Maintenance The GoldKey solution provides a much simpler deployment scenario than OTP tokens. From an administrative point of view, a token can go straight to the end user untouched by IT. All the provisioning, key generation, and privilege associations will be handled by Windows according to policies established in Active Directory. The major convenience advantages of the GoldKey smart card solution over SecurID are: No additional software is required for either Windows Servers (2008 and higher) or client machines (Vista and higher). For Kerberos support, a minimum of Windows Server 2008 R2 and Windows 7 are required if ECC certificates are in use. Provisioning client certificates is user-driven. A feature called auto-enrollment causes the user to be prompted by Windows to enroll for their login certificate. When a certificate is getting ready to expire, Windows automatically prompts the user in advance to enroll for an additional certificate so that no interruptions will occur, eliminating the need for certificate or token replacement scheduling. No management applications are necessary for provisioning or using tokens all these functions are handled natively by the device driver automatically installed by Windows. GoldKey vs RSA Why it s Time to Make the Change 9

10 No expensive or complicated hardware or virtual appliances are needed. Necessary components are already built-in to the Microsoft infrastructure, eliminating the primary and replica Authentication Managers, load balancers, and web tiers that are typical of an RSA deployment. GoldKey tokens do not require batteries or periodic replacement. They sport well over a decade of useful life. Security As already described, the GoldKey PKI approach to multi-factor authentication has some major security advantages over both traditional OTP solutions and some common PKI implementations. PKI-based implementation allows secure authentication to occur without the need for seed files, which are a major weak point in OTP implementations. Private keys are generated in hardware and protected by FIPS-validated components. They never traverse the network not for generation, archival, or use. Use of a private root CA and local subordinate CAs gives you control over network security parameters and the ability to provide better CA private key protection. When the user is supplied with a token, it is not associated with his account, has not been assigned a PIN, and has neither keys generated nor any access granted. This also eliminates any security risks associated with a provisioned token being stolen before it is received by the user. Gold Security The Next-Generation Solution Already Included In GoldKey Tokens With a side-by-side comparison of OTP and PKI technologies, it is easy to see some definite advantages to the PKI approach. Both PKI and OTP have been around long enough to be considered by some as the tried and true, but industry, with its typical hindsight, is starting to see that they've grown some gray hairs. PKI is an amazing technology, especially considering its age (it was invented in the early 1970s). It has held up amazingly well and still serves a good purpose. The problem with PKI is that it does not provide adequate protection against identity impersonation techniques such as man-in-the-middle attacks. The time has come for a next generation, integrated security solution. What is needed is the ability to seamlessly integrate with existing installations while providing the complex and varied technologies that are becoming necessary to withstand new security threats. Gold Security is emerging as the next generation security solution. It utilizes a hierarchical method of managing encryption keys in hardware providing an alternative approach to security based on symmetrical keys and a federated identity system. Every GoldKey Security token provides legacy support with a built-in Smart Card and a fully GoldKey vs RSA Why it s Time to Make the Change 10

11 functional Gold Security capability. Gold Security has emerged with a patented new solution that is filling the holes left by traditional security techniques. The challenge for symmetric key technology has always been key management and secure distribution, especially for remote users. Gold Security combines a hardware-based hierarchical key management system for AES encryption with challenge-response authentication to provide the most secure solution that exists today for both data encryption and identity verification. This new hierarchical approach to AES key management has three tiers GrandMasters, Masters, and User tokens. All user tokens are managed by Master tokens, and Masters by GrandMasters, providing an access management architecture intrinsic to the enterprise authority model. Privileges are delegated out using Security Groups translated to encryption keys generated and securely distributed by the Master and GrandMaster tokens. This technology is called the Hierarchical Security Protocol, or HSP. Using the HSP, enterprises can implement security architectures that have previously been impossible. These include securely sharing data that is encrypted at rest or securely authenticating with web services without resorting to PKI or accepting the existence of the token seed lists or key derivation techniques essential to OTP operation. Since GoldKey security tokens provide built-in Smart Cards and fully functional Gold Security based on HSP, organizations that have deployed certificate-based security for Active Directory are taking advantage of the added features provided by the HSP technology integrated into all GoldKey products. Following a GoldKey PKI deployment, an enterprise immediately has access to the following advanced security solutions: Secure Storage in the Cloud, with enterprise-level sharing coupled with hardware managed access and privilege management. This includes the ability to block tokens that have been lost or stolen, set read-only or read/write privileges, and grant the ability to change access rules. Encrypted storage hosted on existing servers on the local network by utilizing a Secure Portal. This provides all of the sharing and management features of the cloud storage solution with the added features of sharing encrypted volumes and hardware management. Locally-encrypt storage using Secure Drives. Two-factor authentication for supporting websites. PIN recovery and management using Master and GrandMaster tokens or the GoldKey Identity Management website. Two-factor authentication to Microsoft Windows, allowing access to the account to be locked down to an individual or a hardware security group. Encrypted attachments for communication. GoldKey vs RSA Why it s Time to Make the Change 11

12 Until now, a major disadvantage of encryption has been accidental data loss caused by the encryption key becoming inaccessible due to a forgotten PIN or password. In an enterprise, this problem is exasperated by the fact that data encrypted by an employee must be accessible to (and recoverable by) those above that employee in the chain of command. This serious risk in traditional encryption systems is mitigated by HSP because all encrypted data, whether stored locally or in the cloud, is accessible using the registered Master or GrandMaster token, as well as any security group assigned to that data. This recovery path has also been applied to twofactor authentication for Microsoft Windows. Conclusion Many organizations are realizing the increased benefit of the two-pronged and reinvented approach to modern defense security. GoldKey's certificate-based solution is an elegant way to increase your security and ease deployment and administration while at the same time preparing yourself for the next generation of security technology. WideBand Corporation is the only token vendor that offers a complete turn-key solution that is distinguished not only for its level of security, but also for its convenience due to its complete integration with existing standards and infrastructure. A GoldKey deployment offers a smooth transition to the most robust security solution existing today. About WideBand Corporation WideBand Corporation is located in Independence, Missouri. It has been a pioneer in the development of high-tech networking and security products since WideBand is the developer and manufacturer of GoldKey Security Tokens. Deployed by customers in over 40 countries, GoldKey tokens offer shared access to secure storage in the cloud, state-of-the-art data encryption, PIV smart card capabilities, and two-factor authentication to online resources. The company also provides secure cloud storage solutions with their one-million-square-foot, underground data center. The company s Custom Solutions & Deployment Team provides hands-on support to customers with special security needs. GoldKey vs RSA Why it s Time to Make the Change 12

13 References [1] Cryptanalysis of the Alleged (Functionally-Equivalent) SecurID Hash Function [ [2] The RSA Authentication Manager Administrator s Guide [3] Information for this reference may be found in US patent 5,168,520. [4] Security Tokens Take Hit - Wall Street Journal [ [5] RSA s Anatomy of an Attack [ [6] SecurID Company Suffers a Breach of Data Security New York Times [ [7] Smart Card Logon flow in Windows Vista and Windows 7 [ [8] How the Kerberos v5 Authentication Protocol Works [ [9] Chosen-prefix collisions for MD5 applications [ [10] On the possibility of constructing meaningful hash collisions for public keys [ Trademarks EMC, RSA, and SecurID are registered trademarks of EMC Corporation. GoldKey, Gold, and WideBand, are registered trademarks of WideBand Corporation. Lockheed, Lockheed Martin, and Lockheed Martin Corporation are registered trademarks of Lockheed Martin Corporation. Active Directory, Microsoft, Windows, and Windows Server are registered trademarks of Microsoft Corporation. Windows Vista is a trademark of Microsoft Corporation. Copyright 2014 WideBand Corporation All rights reserved. GoldKey vs RSA Why it s Time to Make the Change 13