Sie sind auf Seite 1von 12


Technical Whitepaper

“Since the invention of SUMMARY: Organizations that wish to use strong authentication have a variety of
public key cryptography methods from which to choose. These methods range from simple, traditional
twenty-five years ago, peo- username/password mechanisms that exist in every operating system, to hardware-
ple have been struggling
based one-time password (OTP) tokens, biometric, smart card, and PKI systems.
to secure the private key
However, all of these solutions confirm that higher levels of security is a trade off
without the assistance
of hardware. Arcot's
between cost and convenience. In the past, authentication solutions were either
innovative Cryptographic easy to use and inexpensive, but insecure (such as username/password), or very
Camouflage has solved this secure but expensive or difficult to implement (such as OTP tokens and smart
problem. Finally there is a cards). Arcot offers a third option: WebFort®, a software only, two-factor authentica-
cost-effective and conven- tion solution. WebFort delivers the right balance of cost, convenience, and strength
ient means to strongly for a lower cost of ownership than alternative solutions.
authenticate users and
transactions over the Introducing the ArcotID® An Introduction to PKI
Internet without the need At the heart of WebFort is the ArcotID. The ArcotID is PKI exists to provide secure online authentication
for cumbersome hardware.” the only secure software credential on the market services. Prior to public key cryptography, the princi-
today. It combines the protection for digital IDs like a ple of a “shared secret” formed the basis of authenti-
Martin Hellman
Professor Emeritus, Inventor of PKI hardware smart card with the lower cost and simplicity cation. This time-honored system of passwords, pass
Stanford University phrases, and secret handshakes required both parties
of a software solution. The ArcotID provides strong, two
factor authentication. It is a 100% software solution to arrange to share a piece of information. The critical
that allows organizations to replace simple username/ problem was (and continues to be) how to share a
password or OTP tokens with the strength of a Public particular piece of information between parties when
Key Infrastructure (PKI), without changing the user there is a potentially unlimited number of participants.
experience. The number of shared secrets grows at the rate of the
square (N2) of the number of participants.
The ArcotID features an easy-to-use and familiar user-
name/password interface. It integrates quickly with A better system is a central authority, trusted by all
existing infrastructures with support for standards such parties, that is responsible for authenticating every
as RADIUS-based OTP, SAML, MS CSP and party. This central authority provides all parties with
PKCS#11. Unlike traditional software key containers, credentials that anyone can verify, based on the char-
the ArcotID resists brute-force attacks using patented acteristics of the credential itself. A good example of
“Cryptographic Camouflage”1 technology to hide the this is a passport issued by the government. The gov-
private key from would-be attackers. ernment requires specific forms of proof of identity
before issuing a passport and includes tamper-evident
In addition to strong authentication, the ArcotID technology in the passport itself to reduce the proba-
enables PKI applications such as electronic document bility of forgery. Once issued, the passport is a self-
signing, secure email, and secure ecommerce. As a contained authentication credential.
100% software solution, the ArcotID enables organiza-
tions to leverage the advantages of PKIs without the Public-Key Cryptography
expense and management issues inherent with hard- The basis for PKI is Public Key Cryptography, also
ware-based secure key storage. known as “asymmetric key” cryptography. Public
Key cryptography is a form of encryption where two
1. “Software Smart Cards via Cryptographic Camouflage”, D.N.
Hoover and B. N. Kausik, Proceedings of the 1999 IEEE mathematically related “keys” (seemingly random
Symposium on Security and Privacy, IEEE Computer Society.
Patent 6,170,058

ArcotID Whitepaper

strings of numbers) can be used to encrypt (scramble) and Currently, the primary use of digital certificates is for
decrypt (unscramble) messages and data using a computer. authentication. The significant advantages of certificate-
Messages encrypted with one key can only be decrypted based authentication over other types of authentication are
with the other key and vice versa. threefold: 1) it provides the strong security of two-factor
authentication, 2) it is extremely scalable because it elimi-
The crucial advantage of this property is realized when nates the need for a central directory and 3) it is resistant
these keys are used in a very specific way. Initially the key to man-in-the-middle attacks, most recently in the form of
pair needs to be certified by a trusted third party. One key phishing attacks.
is kept secret by the owner and the second, widely pub-
lished key is tied to the owner's identity. This combination Technically, the advantages are that neither party needs to
creates the foundation for digital signing. In the digital share any private information with the other party before or
world, this is called a PKI. during the authentication process. This eliminates the risk
of accidental disclosure of the password and also elimi-
In this scenario, if the secret or “private” key is used to nates the N2 problem of shared secrets. PKI users can
encrypt a message, then only the widely published and authenticate to other parties with whom they have no prior
certified key (or “public” key) will decode the message relationship by sending their credentials with the initial
correctly. If one can be reasonably sure that the secret or authentication request. This is similar to showing your ID
private key was not stolen, then one can assume that the with your ticket when boarding an aircraft.
decrypted message was indeed sent by the person whose
identity information is contained in the certified public key. A digital certificate-based authentication generally takes
This is the basis for digital signatures. the form of a “challenge-response” transaction. A user
requests a resource from a server. The server then
Digital Signing and Authentication responds with a “challenge” – a time-stamped random
Using additional algorithms such as hashes (see Glossary string of characters that the user receives and signs
at the end of this whitepaper), PKIs can be used to digital- (encrypts) with their private key. The user sends the
ly sign documents and provide the same or even stronger encrypted challenge back to the server along with their
document integrity and authenticity guarantees than digital certificate. The server decrypts the challenge using
paper-based systems. Ultimately PKI’s will enable busi- the user’s public key contained in their certificate. If the
nesses to replace “print and sign” processes with faster, decryption produces the original challenge, the user is
more flexible and more efficient electronic equivalents. authenticated and access is granted. This is shown below
in Figure 1. In most secure transactions, the authentica-
tion is bi-directional; both sides will authenticate them-
selves using digital certificates.


Trusted 3rd Party

1 Request Access

10.06.06 14:04:05
Challenge with timestamp

X.509 Digital Private Key

X.509 Digital
Certificate Certificate
Q354J341(*&!@$ ABJ%4#@B09TE
10.06.06 14:04:05
Issued by trusted X.509 certificate and challenge
3rd party signed with private key Challenge decrypted with
public key from certificate

ArcotID Whitepaper

The Importance of Protecting the Private Key ArcotID Technology

Regardless of the capabilities available to PKI users, PKI The ArcotID was designed to simply and effectively protect
deployments still face a critical challenge – securely and the private key. An ArcotID, like a smart card or USB
cost-effectively storing the private key. In order to validate token, is a secure private key container but delivered
the authentication and maintain the assertion that a digital completely in software. However, unlike other software
signature is binding on the signing party, there needs to be containers, the ArcotID is not subject to “brute force”
a high degree of confidence that the signing party is the attacks in which attackers copy the key container to their
only possible holder of the private key used for signing. own equipment and exhaustively attempt millions of pass-
If there is any doubt, then the possibility exists that an words which eventually leads to the disclosure of the pri-
intruder can steal the key and masquerade as the legiti- vate key. Furthermore, ArcotID key protection software
mate key holder. Even if the key wasn’t stolen, the signer has been validated by NIST under the Federal Information
can still claim that the key might have been stolen and the Processing Standard (FIPS) 140-2, Level 1 ensuring a
signature isn’t his. level of private key protection comparable to hardware at
a fraction of the cost.
Keys can be stored in encrypted software modules,
however they are subject to offline “brute force” attacks The ArcotID prevents brute force and other attack scenarios
(see Figure 2) that can be used to recover keys by exhaus- with Arcot’s patented “Cryptographic Camouflage” technology.
tively attempting all possible passwords. Current comput- Using Arcot’s cryptographic camouflage technology, the key is
ers make this attack quite feasible, especially if users are encrypted based on the user’s password with standard
using easy-to-remember words as passwords. encryption algorithms, but using the patented Arcot process.
The effect of this process is that decryption, even using an
Secure storage is available in the form of Hardware incorrect password, will always produce a result that meets
Security Modules (HSM) and specialized smart cards the specific, particular and well documented characteristics of
called “crypto cards”, both of which permanently safe- a private key. So in the case of a simple 6-digit password, the
guard the private key in hardware. Unfortunately, both brute force attack will produce approximately 56.8 billion
solutions are expensive and require user training, exten- plausible, but invalid private keys. Keys produced as result of
sive hardware deployments and replacement processes. using an invalid password meet all the characteristics of a
These drawbacks have hindered general acceptance of valid key, so they can be functionally used to encrypt or
PKI for digital signatures. “sign” a challenge received from the Arcot server as a part of
the authentication process.


Key Rule: Hex, Begins and Ends with 1

Standard 156F85A750265BA
Software Key Brute Force 17FA3FF43B82C6D
Container Library Attack C1399D66A114E65
6 digit PIN, B4D3A1E75294A4D
56.8 billion results
Protected Key:
• Each is a plausible result.
• The only way to determine the
Secure Software Credential correct key is to sign a challenge
& send to the WebFort server.
1CE59A451B257C1 • If not the right key, the invalid
1DC1A4596B79B21 attempt counter increments by 1.
Brute Force 159CA7C8439BA31
Library Attack
6 digit PIN, 1E459FC479C3B41
56.8 billion results 17675ABC59DE371
Protected Key:

ArcotID Whitepaper

However, to prove that they have obtained the true private key The conventional public-private key pair used in the cre-
protected within the ArcotID, the attacker must move further ation of the certificate for the ArcotID are not the crucial
into the Arcot multi-key authentication process. The attacker part of the credential. When the certificate is received
is forced to encrypt/”sign” the challenge with the password from the CA, the conventional private key is normally dis-
decrypted key and respond to the Arcot authentication server carded, and the conventional public key remains in the
which then determines whether or not a valid password was certificate playing a purely pro forma role. The crucial part
entered. If a valid password is not entered, the server can of the credential is a second public-private key pair.
lock any access to the ArcotID container after a configurable
number of invalid attempts (the default is three), just as with The second key pair that is generated is used for a single
a hardware based solution. The attacker is able to attempt purpose: to authenticate to the Arcot Authentication
only a few passwords and is then prevented from further vali- Server. It is not used for general signing or encryption.
dation attempts. This thwarts offline brute-force attacks and
creates the world’s first truly secure software key container. The public key, shown in the figures as public key 2, is
encrypted with the Domain Key (a key known only to the
Creating an ArcotID Arcot Authentication Server), and then stored in the Arcot
The Arcot strong authentication solution utilizes asymmet- extension in the certificate. The corresponding private key
ric (public key) cryptography as its basis. To this end, a is then "cryptographically camouflaged" using a derivative
(swappable) Certificate Authority is included as one of the of the user's PIN as the encryption key. The camouflaged
components of the Arcot Authentication Solution, and is private key is added as a component of the ArcotID, in
transparently used in the creation of ArcotID credentials. addition to the certificate.

An ArcotID has several components. The first is a standard This completes the creation of a base ArcotID which is
X.509v3 digital certificate with an Arcot-specific extension. delivered to the user as a 2KB file. This ArcotID, in con-
X.509 is a standard that defines, in addition to other things, nection with the Arcot Authentication server, can now be
the structure of digital certificates. According to the stan- used to provide strong user authentication to VPNs, con-
dard, an X.509 certificate contains identity information and a sumer or enterprise secure portals, and other applications
public key. Version 3 of the standard specifies how exten- requiring user authentication.
sions may be added to the certificate structure. This is
shown in Figure 3.


Name: John Q. User

Date Issued: July 7, 2007
Expiration Date: July 7, 2009
Issuer: Arcot: Systems. Inc.
Certificate Authority: MSCA
Public Key 1: 2EF5A810FCB5A


Private Key 2: 1XXXXXXXXXXX1

ArcotID Whitepaper

We observe that the public key in the ArcotID certificate no issued by a private PKI such as an IPSec VPN application
longer has a corresponding private key, and hence is not or by a public CA such as VeriSign or GTE.
useable. Moreover, the "real" key pair is usable only within
the domain where the credential was issued (only a server The third-party Digital ID can be loaded onto an existing
with the Domain Key can access the public key in the certifi- ArcotID or a new ArcotID generated for the Digital ID.
cate extension). This is a feature of the Arcot Authentication Enrollment integration can be accomplished with the Arcot
Solution: – unlike certificates issued by public CA’s, the PKCS#11 driver or with Arcot’s API that integrates with
issuer has full control over what purposes the key can be popular PKI systems such as VeriSign OnSite, MS Certificate
used for, and there is a strictly limited universe of valid users Server, Entrust, RSA Keon and CyberTrust Unicert.
to notify in case any credentials are revoked.
When a Digital ID is loaded into the ArcotID, the Arcot
Secure Digital ID Storage with ArcotID Key Authority creates a unique symmetric key (3DES) to
The ArcotID “Key Vault” encrypt the application private key. The encrypted private
After the core ArcotID is created, it can be used to store key and plain-text certificate are stored in the ArcotID.
and protect application credentials or Digital IDs such as The symmetric key used to encrypt the private key is
digital certificates and private keys. Digital certificates, by stored in a high-security database at the Arcot Key
their nature, are stored but not encrypted. On the other Authority server.
hand, sensitive signing keys (private keys) are strongly
encrypted in the ArcotID file. As previously described in the section “Using ArcotIDs for
Digital Signature Applications”, in order to access the
Figure 4 illustrates the structure of the ArcotID with a third-party private key, the ArcotID will make a request for
“Key Vault”. In this case, a third-party Digital ID is stored the symmetric key to the Authentication Server signed with
in the ArcotID. The private key is encrypted by a key the private key. The Authentication Server authenticates
stored at the Arcot WebFort Key Authority server. The pub- the request and passes it to the Key Authority. The Key
lic key is also stored, but not encrypted in the key vault. Authority then securely sends the symmetric key back to
This private key and certificate (or Digital ID) could be the ArcotID holder. The ArcotID software uses the symmet-


Name: John Q. User

Date Issued: July 7, 2007
Expiration Date: July 7, 2009
Issuer: Arcot: Systems. Inc.
Certificate Authority: MSCA
Public Key 1: 2EF5A810FCB5A


Private Key 2: 1XXXXXXXXXXX1

Public Key 3


Public Key N


ArcotID Whitepaper

1 1. User requests access to web resource*

2. Front end redirects request to
6 front end authentication server
3 3. Authentication server sends challenge to
user via front end
API 4. User enters password to decamouflage
private key, the challenge is signed and
4 2 returned to the authentication server
Resource 5. Authentication server decodes signed
5 challenge and sends success/fail message
to front end
Arcot 6. Front end sets up secure session for
Authentication user to requested resource
*Bold type indicates user experience.

ric key to decrypt the application private key which is then software container or “Key Vault”. This structure is shown
is available to applications for digital signing and other in Figure 3.
cryptographic operations. This complexity is completely
transparent to the user who simply enters his or her pass- ArcotID Client Types and Capabilities
word number in the familiar Arcot user interface to initiate ArcotIDs are secure software credentials which enable
the process. Everything else happens in the background authentication, digital signing, and encryption/decryption.
without user intervention. There are five types of ArcotID clients:
The Structure of an ArcotID 1. Flash Client
An ArcotID is a software container formed of two components. 2. Unsigned Java Applet
The first component is always present and is created when 3. Signed Java Applet
the ArcotID is issued and assigned to an individual; the sec- 4. Standard Installable Client (Native) ActiveX
ond is optional and exists only when an ArcotID is used to pro- 5. Adobe Reader 8/Adobe Acrobat 8 (Embedded in
tect application specific credentials or Digital IDs, such as the Reader/Acrobat for PDF signing)
private key used for digital signature applications.
Flash ArcotIDs can be delivered to the end user’s machine
The first component provides two core functions. The first with no end user or IT administrator involvement. Other IDs
function is to enable the strong authentication capabilities can be installed with minimal effort.
of the ArcotID. Secondly, it forms the basis for the secure


ArcotID Roaming Download 3 3 3 3 3
ArcotID Saved to Desktop *** 3 3 3
ArcotID Saved to USB Drive 3 3 *
Web 3 3 3 3
VPN ** ** ** 3
Digitally Sign Web Forms 3
Digital Signing and Encryption 3
CSP (MS Office) & PKCS#11 (PDF) 3
Digital Signing w/Roaming IDs
Device Lock ArcotID
*** Automatically downloaded and stored in Flash secure object store; not available to copy onto USB, floppy, CD, etc.
** Only for SSL connections through a web browser
* Can use an ArcotID stored on a USB drive, but can not save to USB

ArcotID Whitepaper

Each client has unique attributes and capabilities. A single Using ArcotID natively (via API)
client is capable of handling multiple IDs issued by The most convenient ArcotID client is the flash client since it
different organizations for different purposes. For added requires no administrative downloads. The most versatile
security and flexibility, Native ArcotIDs can be “locked” to ArcotID is the native client, which also allows for Digital
a specific machine when the locking feature is invoked or Signing and has additional security features such as device
can be installed on a USB flash drive for mobility. locking. The process in which the native ArcotID works is
ArcotIDs are compatible with Windows client OS environ- when a user requests access to a protected asset, usually
ments such as 2000 SP4, 2003 SP1, and XP Home and a web page but potentially any digital asset. The server
Professional SP2. Browser compatibility with IE 6, 7, and redirects the request to the authentication plug-in which
Firefox and Firefox 2.0 have also been tested as well. collects the userID from the user. The plug-in then sends
an authentication request to the WebFort Authentication
Table 1 lists the different client types with the associated Server. WebFort then creates a cryptographic challenge
features for each client. which is passed back to the software on the client
machine. This client software (a JavaScript applet on the
Using the ArcotID for Authentication login page or browser plug-in for the native client or an
Authentication using an ArcotID provides the benefit of a SWF file in the case of the Flash Client.) prompts the user
two-factor solution: authentication requires information for their password. The client software uses the password
only the user knows (a password) as well as the user’s to decrypt the private key (which is cryptographically cam-
ArcotID secure Digital ID container. As another layer of ouflaged in the ArcotID) and uses the now decrypted pri-
security, the user must also be able to contact their Arcot vate key to encrypt the challenge sent by WebFort.
Authentication server in order to complete the authentica-
tion transaction. The encrypted challenge is then sent to WebFort along
with the user’s encrypted public key. The Authentication
The Arcot Authentication Server supports a multitude of Server, which is the only server capable of decrypting the
authentication schemes including client-side digital certifi- encrypted public key, uses the decrypted public key to ver-
cate-based authentication for web browsers and VPNs. Arcot ify the signed challenge and authenticate the user. If the
supports standard integration APIs such as MS authentication is successful, WebFort sends a message to
CSP and PKCS#11, one-time-password (OTP)-based authen- the server plug-in to allow the user access. A simplified
tication using the RADIUS protocol as well as native user- flow is shown in Figure 5.
name/ password authentication with Arcot libraries and APIs.



Digital Certificate PKI-based authentication using digital MS Outlook, MS IE, Adobe Acrobat
certificates. Applications natively (Microsoft CSP), Netscape, Mozilla,
support digital certificates accessed Acrobat (PKCS#11)
through standard interfaces (Microsoft

Arcot Username/Password Arcot native authentication method Custom VPN clients, internally developed
accessed with custom API’s or applications using Arcot API, Arcot web
plug-ins. Uses challenge-response server plug-ins.
mechanism to authenticate user.

One-Time-Password (OTP) Arcot server authenticates user using Applications that support RADIUS-based
native Arcot authentication and authentication. Includes examples such as
generates an OTP to be used for VPNs, web applications, ERP applications
authentication to the application. and many others.

ArcotID Whitepaper

1. User requests VPN connection and enters

user ID*
VPN Client 6 VPN Server 2. WebFort VPN Client Plug-in redirects user to
1 WebFort. WebFort sends challenge to VPN
WebFort VPN Client Plug-in
Client Plug-in 3. User enters PIN, challenge is signed and
returned to WebFort
7 4. WebFort may optionally use RiskFort as part
2 5 of authentication
3 5. One Time Password (OTP) sent to WebFort
VPN Client Plug-in
6. VPN Client sends OTP to VPN Server
WebFort 4 RiskFort 7. VPN Server validates OTP with WebFort via
RADIUS, then establishes session with
VPN Client
*Bold type indicates user experience.

Using ArcotID for OTP Generation with RADIUS authorization server which passes the OTP back to
Remote Authentication Dial-In User Service or RADIUS is an WebFort via RADIUS. The user is approved by WebFort
industry-standard interface for providing authentication, and the user authenticated message is returned to the
authorization and accounting (AAA) services to remote- authorization server. The server then permits the user to
access solutions. Using RADIUS, IT managers can deploy access the asset.
remote access solutions and plug in their choice of authenti-
cation products. RADIUS is supported by virtually every Despite the strong security and cryptographic complexity
remote access product currently available. The WebFort of the actual authentication, the user still sees a familiar
Authentication Server includes a RADIUS server which username/password interface and the asset server inte-
enables easy integration with existing access solutions. grates to a standard RADIUS server using OTP. This insis-
tence on standard interfaces, both for end-users and IT
RADIUS authentication is an example of “pass-through” processes is a critical factor in Arcot’s success.
authentication. The access device itself does not have native
authentication capabilities so credentials provided by the This process is illustrated graphically in Figure 6. In this
user (for example, a username/password combination, example, the user is attempting to authenticate to a VPN.
username and OTP, signed challenge and certificate, O/S The VPN Server is acting as the authorization server protect-
credentials token, etc.) are passed through to the authen- ing the asset (the network). For more information on Arcot’s
tication server for verification. VPN authentication solutions, please see the “Strong
Authentication for Secure VPN Access” solution guide.
When a user with an ArcotID requests access to an asset
protected by WebFort, the server protecting the asset has Using ArcotID to Authenticate with Digital IDs
two options; one is to proxy a challenge/response transac- Some applications such as web applications and VPNs
tion between the WebFort server and the client. The other have the ability to use client certificates or “Digital IDs” for
is to redirect the authentication to the WebFort server. In user authentication. For these users, the problem of
the latter case, the WebFort server sends a cryptographic securely and cost-effectively protecting the private key is
“challenge” directly back to the user’s machine. The paramount. ArcotID functions as a strong software key
Arcot client software, which can be as simple as a container and can integrate seamlessly with these applica-
JavaScript web script, a VPN client plug-in, or a full-fea- tions with both Microsoft Crypto Service Provider (MS
tured signing application prompts the user for his or her CSP) and PKCS #11-compatible client software. Users
username and password. Using the private key decrypted can enjoy the same VPN or web interface they are accus-
by the password, the client software then signs the chal- tomed to but gain the advantages of the ArcotID strong,
lenge sent by WebFort and returns it. If the password is two-factor security. Figure 7 shows how the ArcotID inte-
correct and the challenge is properly signed, WebFort grates with a PKI-enabled application. Note that using the
returns a One-Time-Password (OTP) to authenticate the solution requires no changes to the PKI-enabled application.
user. In general, this OTP is automatically passed to the

ArcotID Whitepaper



CSP Provider Arcot CSP Provider Arcot

CSP Driver PCKS #11 Driver

PCKS #12 Software Smart Card

Key Container Key Container

A popular use of client certificates is authentication with 3DES symmetric key used to decrypt the private key origi-
“browser certificates” or certificates obtained with and stored nally requested. The private key is then available for use
in a web browser’s certificate store. For Internet Explorer, by the CSP.
this certificate store is called a Crypto Service Provider (CSP)
and is chosen when the certificate is initially issued. For While the actual process to release the private key is very
Netscape-derived browsers such as Mozilla and Firefox, secure, the user experience remains a simple username/
the default certificate store is a PKCS #12 certificate store. password interface.
Both storage mediums are software-based and password-
protected but unfortunately, both are subject to offline Using ArcotIDs for Digital Signature Applications
brute force attacks. The truly unique feature of PKI is enabling digital signing.
The promise of moving physical “print and sign” processes
When an ArcotID is used to store the credentials, the same to a pure digital document environment is an enormous driv-
certificates can be used in exactly the same manner using er for such paper-driven industries as pharmaceuticals,
the same browsers but they will be protected using Arcot’s health-care, banking, lending and especially government.
patented Cryptographic Camouflage, secure from attack. The secure storage of digital IDs is still a barrier to wide-
Details of the storage mechanism are provided in the Secure spread adoption because of the potential for fraud and the
Digital ID Storage with ArcotID section on page 5. subsequent loss of confidence due to compromised digital
credentials. The ArcotID can be used to store third-party
Implementing Digital ID-based authentication with ArcotID digital IDs (certificates and private keys) in a secure manner.
is similar to the native ArcotID authentication. Client
machines must have the Arcot CSP or Arcot PKCS #11 The Secure Digital ID Storage with ArcotID section on
driver installed. When the client application requests page 5 describes the mechanics of how a third-party cer-
access to the private key contained in the ArcotID, the tificate and private key can be stored in the ArcotID. Using
Arcot client software initiates a connection to the WebFort a third-party certificate for digital signatures is however, a
server requesting access to the key. The WebFort server straight-forward process very similar to that described
issues a cryptographic challenge which is returned to the above in the authentication section. The primary differ-
Arcot client software. The user is then prompted for their ence is how the credentials are accessed.
password to access the cryptographically camouflaged
ArcotID private key. The challenge is encrypted with the There are two primary methods for accessing credentials for
de-camouflaged private key and sent back to the WebFort digital signatures. The first, as described above is implement-
server. If the password is entered correctly, the challenge ed using an Arcot CSP or PKCS#11 driver. When the client
will be decrypted and the WebFort server will return a application requests access to the private key contained in

ArcotID Whitepaper

Name: John Q. User Authentication
Date Issued: July 7, 2007 1 Server
Expiration Date: July 7, 2009
Issuer: Arcot: Systems. Inc. 3 Digital
Certificate Authority: MSCA
PIN Request/ Signature
Public Key0: 2EF5A810FCB5A
4 Decryption Domain Key
Key Request
Arcot Key
Signing Key 4 Authority
(holds decryption
5 Decryption Key
6 keys)

Key Request

Digital Signature 1. User presses “sign document” button*

Key & Certificate 2. Acrobat requests signing key from ArcotID
7 3. User is prompted for and provides PIN
4. ArcotID requests 3DES decryption key
5. Server provides 3DES decryption key
2 6. Signing key decrypted with 3DES key
Digital Signature 8 7. Signing key returned to Acrobat
Key Request 8. Acrobat creates signed document
*Bold type indicates user experience.

the ArcotID, the Arcot client software initiates a connection An example of the digital signature process is illustrated
to the WebFort server requesting access to the key. The in Figure 8 – Signing Adobe Acrobat documents using
WebFort server issues a cryptographic challenge which is credentials stored in ArcotID. Note that only steps 1 and 3
returned to the Arcot client software. The user is then involve user interaction – everything else happens automat-
prompted for their username and password to access the ically behind the scenes.
cryptographically camouflaged ArcotID private key. The
challenge is encrypted with the de-camouflaged private Conclusion
key and sent back to the WebFort server. If the password is The ArcotID provides the most cost-effective, secure Digital ID
entered correctly, the challenge will be decrypted and the storage available anywhere. Using patented Cryptographic
WebFort server will return a 3DES symmetric key used to Camouflage technology, the ArcotID provides unprecedented
decrypt the private key originally requested. The private software security for digital credentials while preserving
key is then available for use by the CSP and/or requesting the ease-of-use critical to the success of any authentication
application. solution.

An example of this would be sending digitally signed email With the ArcotID, you can easily add strong authentication
with Outlook. After composing the email, the user clicks the to Web applications, Virtual Private Networks (VPNs), intra-
checkbox for a signed email and presses the send button. enterprise usage, and you can enable other solutions like
Instead of being prompted by the default CSP for a password secure signing and secure delivery bill payments. The
to access the private key, the user is prompted for their ArcotID’s decryption functionality enables the secure deliv-
ArcotID username and password. After the authentication ery of encrypted PDFs directly to your user’s email inbox,
process takes place with WebFort and the key is released, the for such uses as billing statements, medical records, or
Arcot CSP signs the message hash provided by Outlook and purchase orders. You can even enable users to digitally
the signed email is sent. No changes are required to Outlook sign Adobe PDFs with the ArcotID.
and the user interface remains familiar.

ArcotID Whitepaper

ArcotIDs can ensure that you’ve protected your critical Encryption

business systems and that your company is adhering to Also known as symmetric encryption, it is the act of scram-
regulatory compliance laws. bling data so only the intended recipient can unscramble it.
Both sender and recipient must share the same encryption
Glossary key to scramble and unscramble the data.
Certificate Authority (CA)
A certificate authority is responsible for signing digital cer- Hash
tificates.Once a digital certificate is signed by a CA, anyone A hash, also known as a message digest, is a number gener-
with the CA’s digital certificate can verify the authenticity of ated from a string of text. The hash is substantially smaller
any digital certificate signed by that CA. This process is than the text itself, and is generated by a formula in such a
also called “issuing digital certificates”. way that it is extremely unlikely that some other text will pro-
duce the same hash value. Hash functions are well-known
Cryptographic Camouflage and will always produce exactly the same result when per-
Arcot’s patented cryptographic camouflage is used to pro- formed on the same text.
tect Digital IDs stored in the ArcotID. Regardless of the
password used to gain access, the result will always be a Hardware Security Module (HSM)
plausible key. This prevents users from attempting offline HSMs securely generate and/or store long term "secrets"
attacks on the ArcotID as they cannot know if they have for use in Cryptography and physically protect the access
discovered the right password without validating the result to and use of those secrets over time. Generally these are
online. After a few failed attempts, the users account can private keys used in Public-key cryptography; some HSMs
be locked out, foiling any attempts to “crack” the ArcotID. also allow for hardware protection of symmetric keys.

Digital Certificate Identity

A digital certificate contains a users public key and identity The identifying characteristics of a user. These could
information and is signed by a trusted third party known include the users name, phone number, email address,
as a Certificate Authority. employer, country of residence or any other information
appropriate to the application.
Digital ID
A Digital ID is the digital equivalent of a driver’s license or Key Storage
passport. It contains information called a Digital Certificate Private keys are very sensitive to disclosure as their com-
which includes the holder’s identity (name, email, address promise can result in impersonation and fraud. Key stor-
etc.) and is certified to be valid by a trusted third party age ranges from simple software containers which are
(Certificate Authority). A Digital ID also contains a Private Key generally insecure to expensive but secure crypto-cards
that can be used to digitally sign electronic documents. which perform all signing operations within the card.
Arcot’s ArcotID provides the security of a hardware smart
Digital Signature card with the ease of use of software.
A digital signature is a combination of two processes. The
first is creating a hash of the data or document to be Non-repudiation
signed. Then the user signs the hash using their private Non-repudiation is an important feature of PKI. When
key. By validating the signature using the user’s digital cer- used properly, A PKI-based system can prevent a user
tificate and comparing the signed hash to a locally-calcu- from denying responsibility for legitimate actions (signed a
lated hash of the document or data, the receiving user ver- document, authenticated, sent a message etc.) that
ifies not just the identity of the signer but the integrity of required them to use a digital ID. Since the user is the
the data or document. only one with access to the digital ID, they cannot disown
actions taken with it.

Private Key certificates. This includes a CA, directories for stor-
A private key is used to sign an electronic document ing identity information and other services. PKIs are
or any electronic data. The corresponding Public generally public (for example VeriSign) or private
Key is used to verify the signature. Since anyone (for example Entrust).
who possesses the private key can sign an electron-
ic document with it, the private key must be very Revocation
well protected to avoid others masquerading as the When a user is no longer authorized to use a Digital
intended key holder. ID, the ID must be revoked. This process can be
difficult with standard PKIs however Arcot’s system
Public Key is designed to make this process easier.
A public key is used to verify a signature performed
with a private key. In general, a public key is con- Signing
tained in a Digital Certificate along with identity The act of encrypting a piece of data (usually a hash)
information for the owner. In this way, a digital sig- with a private key.
nature validated with a public key contained in a
digital certificate can be used to verify who signed a X.509v3 Digital Certificate
digital document. X.509 is a specification for digital certificates published
by the ITU-T (International Telecommunications Union
Public Key Encryption — Telecommunication). It specifies information and
Also known as asymmetric encryption, public key attributes required for the identification of a person or a
encryption is a form of encryption where there are computer system. Version 3 (X.509v3) defines the for-
two keys instead of one. One key, the private key, is mat for certificate extensions which can be used to add
used to encrypt (scramble) and the other, the public additional certified information to the certificate such as
key, is used to decrypt (descramble). titles, authorities or other application specific data.

Public Key Infrastructure (PKI )

A PKI is a phrase used to describe the entire infra-
structure necessary to support the use of digital

About Arcot
Arcot is the cloud authentication
leader. Our fraud prevention,
strong authentication, and
e-Document security solutions
make Web transactions and
online access safe for millions
of consumer, enterprise, and
e-Commerce users.
Organizations can transparently
deploy stronger authentication
and allow users to conveniently For more information, please visit, email, or contact your nearest sales office:
authenticate from any computer
Corporate Headquarters, U.S. United Kingdom Germany India
or mobile device. Arcot solutions Arcot Systems, Inc. Arcot International Arcot Deutschland GmbH Arcot R&D Software Private Ltd
deliver the right balance of cost, Ph: +1 408 969 6100 Ph: +44 118 965 7998 Ph: +49 8157 997793 Ph: +91 80 6660 2745
convenience and strength.
Copyright © 2010 Arcot Systems, Inc. All rights reserved. Arcot, Arcot WebFort and ArcotID are registered trademarks of
Arcot Systems, Inc. All other trademarks are the property of Arcot Systems, Inc. or their respective owners. 10-84