GoldKey vs RSA

Why it’s Time to Make the Change

Analysis of Current Technologies for

Multi-Factor Authentication in Active Directory

WideBand Corporation

www.GoldKey.com

GoldKey vs RSA – Why it’s Time to Make the Change 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 two-

factor 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 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 multi-

factor 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 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 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 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 email 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 auto-

enrollment 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 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 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 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 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 20-20 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 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 email communication.

GoldKey vs RSA – Why it’s Time to Make the Change 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 two-

factor 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 1991. 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 13

References

[1] Cryptanalysis of the Alleged (Functionally-Equivalent) SecurID Hash Function

[http://eprint.iacr.org/2003/162.pdf]

[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

[http://online.wsj.com/news/articles/SB10001424052702304906004576369990616694366]

[5] RSA’s Anatomy of an Attack [https://blogs.rsa.com/anatomy-of-an-attack]

[6] SecurID Company Suffers a Breach of Data Security – New York Times

[http://www.nytimes.com/2011/03/18/technology/18secure.html]

[7] Smart Card Logon flow in Windows Vista and Windows 7 [http://technet.microsoft.com/en-

us/library/92aea8c5-c617-4a04-9356-e0ad8dd4cea9(v=ws.10)]

[8] How the Kerberos v5 Authentication Protocol Works [http://technet.microsoft.com/en-

us/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f28]

[9] Chosen-prefix collisions for MD5 applications

[https://documents.epfl.ch/users/l/le/lenstra/public/papers/lat.pdf]

[10] On the possibility of constructing meaningful hash collisions for public keys

[http://www.win.tue.nl/~bdeweger/CollidingCertificates/ddl-full.pdf]

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.