EzIdentity MFA-TechnicalWriteup

EzIdentity™ Authentication Platform
Security and Technical overview

Last Modified: June 22, 2010
This document is CONFIDENTIAL and a TRADE SECRET of EZMCOM INC. Sunnyvale, California, USA. The receipt or possession of this document does not convey any rights
to reproduce or disclose its contents, use, or sell anything that it may describe, in whole or in part, without the specific written consent of EZMCOM Inc. Any reproduction
of this document without the express written consent of EZMCOM Inc. may subject you/your organization to civil and/or criminal prosecution.
Table of Contents
1.0 Introduction ................................................................
................................................................................................
.................................................................
................................. 4
1.1 Scope of document................................
document................................................................
................................ ................................................................
................................ ..................................
................................ .. 4
1.2 Get help ................................................................

................................ ................................................................
................................ .................................................
................................ ................. 4
1.2.1 Contact Technical Support ............................................................................... 4
2.0 OTP Generation ................................................................

............................................................................................
............................................................ 5
2.1 Hardware OTP Token ................................................................
................................ ...............................................................
................................ ............................... 5
2.2 Software | SMS OTP Token ................................................................

................................ .......................................................
................................ ....................... 6
2.2.1 HOTP Algorithm .............................................................................................. 6
2.2.2 Notation and Symbols ...................................................................................... 6
2.2.3 Description...................................................................................................... 7
2.2.4 Generating an OTP Value ................................................................................. 8
3.0 OTP Token Credential Security ................................................................

....................................................................
.................................... 10
3.1 Token Key Management ................................................................
................................ .........................................................
................................ ......................... 10
3.2 Dual Control ................................................................

................................ ................................................................
................................ .........................................
................................ ......... 11
3.3 Initialization of Token import key ................................................................

................................ ...........................................
................................ ........... 11
3.4 Import tokens ................................................................

................................ ................................................................
................................ .......................................
................................ ....... 13
4.0 EzIdentity™ - Role based access control ......................................................

...................................................... 16
5.0 Data Store security ................................................................

.....................................................................................
..................................................... 18
5.1 Encrypted Token Secrets ................................................................
................................ ........................................................
................................ ........................ 18
5.2 Encryption standards and algorithms ................................................................

......................................................................
................................ ...... 18
6.0 Network and Systems access control security ...............................................

................................ ............... 20
Security and Technical Overview  2008-2009 EZMCOM, Inc. All rights reserved. Page 2
List of Figures
Figure 3-1: Sample Software Token credentials file .............................................................. 10
Figure 3-2: Sample Hardware Token credentials file ............................................................ 10
Figure 3-3: Login to portal.................................................................................................. 11
Figure 3-4: Set Token Import Key – Save the Token credentials import key ........................... 12
Figure 3-5: Login to operator portal .................................................................................... 13
Figure 3-6: Import Token – Select the Hardware OTP Token Type ......................................... 14
List of Tables
Table 5-1: Encryption standards and algorithms ............................................................................. 18
1.0 Introduction
EzIdentity™ is a versatile authentication platform that provides a centralized set of
services across multiple service channels and business units. Supporting a variety of
authentication methods, EzIdentity™ is highly scalable and easy-to-integrate. Business
units can select the type of authentication (such as Public Key Infrastructure (PKI)
credentials, Software or Hardware based One-Time Password (OTP) — or SMS/ TAC
based authentication or mix of chosen modes of authentication.
1.1 Scope of document

This document explains key management aspects and the Tokens other security aspects
of the Product.
1.2 Get help

If you require further clarification and details on the security and regulation compliance
of EzIdentity™, you can contact your customer support personnel appointed by EZMCOM
or email your sales representative for this product.
1.2.1 Contact Technical Support

If your question requires one-on-one help from an expert, EZMCOM support
professionals are available to help. Please send questions by email to
support@ezmcom.com.
2.0 OTP Generation
This section describes the various security algorithms and standards implemented for
the OTP generation.
2.1 Hardware OTP Token

For the hardware OTP Tokens, EzIdentity™ supports Authenticard-I algorithm for OTP
generation and verification. Triple DES encryption (112-bit key is used for encryption for
the Token credentials.
To produce a dynamic password (and since secrets are static) the OTP-Token needs to
feed its crypto-engine with both internal clock time and secrets. The time duration that
defines how often a new dynamic password is generated. This is the TIME STEP which
has a recommended setting of 32 seconds.
In a perfect world, the EzIdentity™ server and OTP-Token time are perfectly
synchronized. The server just has to deal with the current Time Step – any other
dynamic password would be rejected. But our real world is not perfect. The OTP needs a
certain amount of time to reach the server for verification based on the average user’s
speed of OTP Token operation and the internet or network latency for OTP to reach the
EzIdentity™ server for verification. To address this challenge, EzIdentity™ Time Drift
Management consists of accepting more than one dynamic password during a given
period as a valid password. This period can be configured as [N * Time Step].

Step]. Let’s say,
N = 3 and Time Step = 32 seconds, the OTP validity period termed now onwards as
TIME WINDOW for OTP verification becomes 96 seconds.

seconds
2.2 Software | SMS OTP Token
For the software based and SMS OTP Tokens, EzIdentity™ supports OATH HOTP (RFC
4226) - Open Authentication standards for One-Time Password generation and
verification. Triple DES encryption (112-bit key is used for encryption for the Token
credentials. This section introduces first the context around an algorithm that generates
one-time password values on HMAC and, thus, is named the HMAC-Based One-Time
Password (HOTP) algorithm.
2.2.1 HOTP Algorithm

In this section, we introduce the notation and describe the HOTP algorithm basic blocks
-- the base function to compute an HMAC-SHA-1 value and the truncation method to
extract an HOTP value.
2.2.2 Notation and Symbols

A string always means a binary string, meaning a sequence of zeros and ones.
If s is a string, then |s| denotes its length.
If n is a number, then |n| denotes its absolute value.
If s is a string, then s[i] denotes its i-th bit. We start numbering the bits at 0, so s =
s[0]s[1]...s[n-1] where n = |s| is the length of s.
Let StToNum (String to Number) denote the function that as input a string s returns the
number whose binary representation is s. (For example, StToNum(110) = 6.)
Here is a list of symbols used in this document.
Symbol Represents
C 8-byte counter value, the moving factor. This counter MUST be
synchronized between the HOTP generator (client) and the HOTP
validator (server).
K Shared secret between client and server; each HOTP generator has
a different and unique secret K.
T Throttling parameter: the server will refuse connections from a
user after T unsuccessful authentication attempts.
s Resynchronization parameter: the server will attempt to verify a
received authenticator across s consecutive counter values Digit
number of digits in an HOTP value; system parameter.
2.2.3 Description
The HOTP algorithm is used for generating One Time Passwords. Each such password is
associated with an expiry time. A new OTP is generated based on an increasing counter
value and a static symmetric key associated only with the user. In order to create the
HOTP value, we will use the HMAC-SHA-1 algorithm, as defined in RFC 2104.
As the output of the HMAC-SHA-1 calculation is 160 bits, we must truncate this value
to something that can be easily entered by a user.
HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))
Where - Truncate represents the function that converts an HMAC-SHA-1 value into an
HOTP value as defined in Section 2.2.4.

2.2.4
The Key (K), the Counter (C), and Data values are hashed high-order byte first. The
HOTP values generated by the HOTP generator are treated as big endian.
2.2.4 Generating an OTP Value

The HOTP algorithm is used for generating an OTP value. We can describe the
operations in 3 distinct steps:
Step 1: Generate an HMAC-SHA-1 value Let HS = HMAC-SHA-1(K,C) // HS is a 20-byte
string
Step 2: Generate a 4-byte string (Dynamic Truncation)
Let Sbits = DT(HS) // DT, defined below, // returns a 31-bit string
Step 3: Compute an HOTP value
Let Snum = StToNum(Sbits) // Convert S to a number in
0...2^{31}-1
Return D = Snum mod 10^Digit // D is a number in the range
0...10^{Digit}-1
The Truncate function performs Step 2 and Step 3, i.e., the dynamic truncation and then
the reduction modulo 10^Digit. The purpose of the dynamic offset truncation technique
is to extract a 4-byte dynamic binary code from a 160-bit (20-byte) HMAC-SHA-1
result.
DT(String) // String = String[0]...String[19]
Let OffsetBits be the low-order 4 bits of String[19]
Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
Let P = String[OffSet]...String[OffSet+3]
Return the Last 31 bits of P
The reason for masking the most significant bit of P is to avoid confusion about signed
vs. unsigned modulo computations. Different processors perform these operations
differently, and masking out the signed bit removes all ambiguity.
Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit
code. Depending on security requirements, Digit = 7 or more SHOULD be considered in
order to extract a longer HOTP value.
The following paragraph is an example of using this technique for Digit = 6, i.e., that a
6-digit HOTP value is calculated from the HMAC value.
3.0 OTP Token Credential Security
3.1 Token Key Management
This section explains the aspects of security and secret key protection measures in the
EzIdentity™ platform. To enable authentication, one pre-requisite is to import the Token
Secret files purchased / procured from EZMCOM. Please contact EZMCOM Sales
Department for further information about the Token Secret files.
Sample contents of a Software Token and a Hardware Token file is as illustrated below:
Figure 3-1: Sample Software Token credentials file
Figure 3-2: Sample Hardware Token credentials file
Each such Token file contains the Secret Key associated with the Software or Hardware
Token. These secrets are always encrypted using industry standard symmetric
encryption algorithms such as Triple DES/ AES. An unauthorized exposure of this file
does not compromise the Token Secrets as they are only seen in their encrypted form
within the file.
3.2 Dual Control

The procurement of the Software or Hardware Token files is accompanied with the
issuance of “Token import key” in a separate channel of communication – PIN Mailer/ E-
mail. This out-of-band communication of the “Token import key” is generally made to
the IT Security/ CIO/ CISO or the designated Project owner of the deployment. This
ensures that at there is no exposure of the Token secrets at an operational level. The
process of importing the Token files into EzIdentity™ is not possible unless the “Token
import key” is initialized into the system.
EzIdentity™ provides two separate web based portals for a dual-controlled key
management of the Tokens:
• Operator Portal: This portal allows import of the Token files by users/ operators
of EzIdentity™
• Administration Portal: This portal allows initialization of the “Token import key”
prior to upload of the Token files in the Operator portal.
Each portal may have its own access control and disparate set of users. The “Token
import key” must be initialized into EzIdentity™ before uploading the Token files from
the Operator portal. Not doing so will result in a failure while uploading the Token files.
3.3 Initialization of Token import

import key
The administration and configuration web based portal of EzIdentity™ - Management
Portal allows the initialization of the “Token import key”. This section explains how to
initialize EzIdentity™ with the “Token import key”.
1. Go to the URL to access the Security Administration Portal.
Figure 3-3: Login to portal
NOTE: Please refer to section 4.0 EzIdentity™ - Role based access control on Page 16 for
details on security control and role based access.
2. Enter valid credentials to log on.
Enter your login credentials to get access to the Security Administration portal as per
the deployment – Either your AD/ LDAP/ Database credentials or as initialized during
system deployment.
3. Click Configure
Configure Group.
Group Select “Token Settings” from the settings from the navigation
menu and select “VASCO DPX key” from the drop down menu as per choice of Token
being uploaded.
Figure 3-4: Set Token Import Key – Save the Token credentials import key
The Save Configurations option is displayed, allowing you to enter the “Token Import
Key”.
Key” Refer to the out-of-band communication PIN mailer/ E-mail to obtain the key for
the batch of Token files to be imported. The Save Configuration button allows you to
save the “Token import key” and prepare the EzIdentity™ system to allow the import and
upload of the Software/ Hardware token files on the computer. Importing the Token files
3.4 Import tokens

1. Go to the URL to access the Operator Portal.
Figure 3-5: Login to operator

operator portal
NOTE: Please refer to section 4.0 EzIdentity™ - Role based access control on Page 16 for
details on security control and role based access.
2. Enter valid credentials to log on.
3. Click Import Token.

Token Select Token Type.
Figure 3-6: Import Token – Select the Hardware OTP Token

Token Type
Figure 3-4: Import Token – Browse and import
The Browse options are displayed, allowing you to locate the token secret file on the
computer. Your tokens will be available in a one of more supported format file (e.g.
SOFT_TOKEN_SECRETS.xml or HARDWARE_CR_TOKEN_SECRET.dpx). These files will
contain tokens shared secret information along with serial numbers that gets imported
in EzIdentity.
4. Browse to the Token file(s) and click of Upload.
5. Click Import to complete the upload.
6. Confirm that the tokens were imported successfully by checking the displayed
status. You can also check the upload status of tokens in Inventory.
4.0 EzIdentity™
EzIdentity™ - Role based access
control
EzIdentity™ provides a granular, role based access control to its operator, administration
portals. The following access matrix establishes the various levels and roles based
classification that are available.
Functions User Super User Administrator
Assign Token ∎ ∎
Un-assign Token ∎ ∎
HelpDesk ∎ ∎
Activate, Synchronize, Unlock, Lock, Lost, Resend activation code
Activate Software Token ∎ ∎
Inventory view ∎ ∎
Import Token ∎ ∎
Reports ∎ ∎
Assign and Manage Operator users ∎
Assign roles to operator users ∎
Create customer group (domain) ∎
OTP Token security and configuration ∎

OTP length, Token import key, SMS TAC validity, Activation Code
validity, Soft Token wallet configuration etc.
Signature OTP security and configuration ∎

Secure hash seed
Encryption key configuration ∎

SSO encryption key setting
External User store configuration ∎

Database configuration (JDBC URL, username, password, SQL)
AD/ LDAP configuration (Admin DN, Base DN, admin username,
password etc.)
Create operator group (domain) ∎
Assign super operators ∎
Product License Configuration ∎
5.0 Data Store security
The above sections explain the dual control approach of uploading the token files. In
this section, the security of the Token secrets within the data store of EzIdentity™ is
explained.
5.1 Encrypted Token Secrets

Once successfully imported, the Token secrets are stored securely in the data store of
EzIdentity™ by industry standard Public key encryption algorithms. The secrets are
always in their encrypted form – encrypted by the “Token import key”. On a successful
upload, these Token import keys are securely stored for further decryption of the token
secrets as needed in the internal workflow of the system. The Token import keys are
encrypted and stored by the Public Key of the server and then decrypted using the
Private keys of the EzIdentity™ server. The key-pair of the EzIdentity™ server are auto-
initialized during the product installation and are stored protected with the container
fingerprint of the Hardware Server separate from the data store of the Token secrets.
5.2 Encryption standards and algorithms

Table 5-1: Encryption standards and algorithms
Scope Algorithm Algorithm description
Token File – Triple DES Triple DES uses a "key bundle" which comprises three DES keys, K1, K2
Secret and K3, each of 56 bits (excluding parity bits). The encryption algorithm
Encryption is:
ciphertext = EK3(DK2(EK1(plaintext)))
i.e., DES encrypt with K1, DES decrypt with K2, then DES encrypt with K3.
Decryption is the reverse:
plaintext = DK1(EK2(DK3(ciphertext)))
I.e., decrypt with K3, encrypt with K2, then decrypt with K1.
Each triple encryption encrypts one block of 64 bits of data.
Data store – Public Key Public key encryption — a message encrypted with a recipient's
Token secret Encryption
public key cannot be decrypted by anyone except a possessor
encryption
Scope Algorithm Algorithm description
PKCS#1 of the matching private key -- presumably, this will be the
owner of that key and the person associated with the public
key used. This is used for confidentiality.
6.0 Network and Systems
Systems access control
security
The communication between EzIdentity™ and other systems (e.g. Internet Banking
application, SMS Gateway) in the deployment is regulated with Transport Layer Security
(TLS/ SSL) utilizing the industry standard 128-bit SSL/ TLS over 1024-bit RSA key pairs.
The communication is also regulated with appropriate firewall rules of allowing access
from trusted servers (IP addresses and Ports) within the secure segment of deployment.
Access to any external data store – viz. Database is access controlled by providing
specific user credentials (schema) that allow EzIdentity™ need-basis and limited access.
The overall Physical, Network and access control security specifications are established
prior to a deployment to eliminate any possible breach of security and exposure.
Send us your comments

EZMCOM Inc. welcomes your comments and suggestions.
Your input is an important factor in future revisions of this publication. Please let us know your
opinion.
Product:
Product EzIdentity™ Authentication Platform
Document:
Document Security and Technical Overview
Please send your feedback to:
to feedback@ezmcom.com
If you find errors or have general suggestions for improvement, please indicate the chapter, section,
and page number.
If you would like a reply, please include your name, company, email address, and telephone number.
Important:
Important If you have problems with the software, please contact your EZMCOM representative.

EzIdentity MFA-TechnicalWriteup

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

EzIdentity MFA-TechnicalWriteup

Încărcat de

Drepturi de autor:

Formate disponibile

EzIdentity™ Authentication Platform

Security and Technical overview

1.2 Get help ................................................................

1.2.1 Contact Technical Support ............................................................................... 4

2.0 OTP Generation ................................................................

2.2 Software | SMS OTP Token ................................................................

2.2.1 HOTP Algorithm .............................................................................................. 6

2.2.2 Notation and Symbols ...................................................................................... 6

2.2.4 Generating an OTP Value ................................................................................. 8

3.0 OTP Token Credential Security ................................................................

3.2 Dual Control ................................................................

3.3 Initialization of Token import key ................................................................

3.4 Import tokens ................................................................

4.0 EzIdentity™ - Role based access control ......................................................

5.0 Data Store security ................................................................

5.2 Encryption standards and algorithms ................................................................

6.0 Network and Systems access control security ...............................................

Figure 3-1: Sample Software Token credentials file .............................................................. 10

Figure 3-2: Sample Hardware Token credentials file ............................................................ 10

Figure 3-3: Login to portal.................................................................................................. 11

Figure 3-5: Login to operator portal .................................................................................... 13

Table 5-1: Encryption standards and algorithms ............................................................................. 18

1.1 Scope of document

1.2 Get help

1.2.1 Contact Technical Support

the OTP generation.

2.1 Hardware OTP Token

the Token credentials.

has a recommended setting of 32 seconds.

period as a valid password. This period can be configured as [N * Time Step].

TIME WINDOW for OTP verification becomes 96 seconds.

4226) - Open Authentication standards for One-Time Password generation and

Password (HOTP) algorithm.

2.2.1 HOTP Algorithm

extract an HOTP value.

2.2.2 Notation and Symbols

If s is a string, then |s| denotes its length.

If n is a number, then |n| denotes its absolute value.

s[0]s[1]...s[n-1] where n = |s| is the length of s.

number whose binary representation is s. (For example, StToNum(110) = 6.)

Here is a list of symbols used in this document.

C 8-byte counter value, the moving factor. This counter MUST be

synchronized between the HOTP generator (client) and the HOTP

a different and unique secret K.

T Throttling parameter: the server will refuse connections from a

user after T unsuccessful authentication attempts.

s Resynchronization parameter: the server will attempt to verify a

received authenticator across s consecutive counter values Digit

number of digits in an HOTP value; system parameter.

to something that can be easily entered by a user.

HOTP value as defined in Section 2.2.4.

2.2.4 Generating an OTP Value

operations in 3 distinct steps:

Step 1: Generate an HMAC-SHA-1 value Let HS = HMAC-SHA-1(K,C) // HS is a 20-byte

Step 2: Generate a 4-byte string (Dynamic Truncation)

Let Sbits = DT(HS) // DT, defined below, // returns a 31-bit string

Step 3: Compute an HOTP value

Let Snum = StToNum(Sbits) // Convert S to a number in

Return D = Snum mod 10^Digit // D is a number in the range

is to extract a 4-byte dynamic binary code from a 160-bit (20-byte) HMAC-SHA-1

Let OffsetBits be the low-order 4 bits of String[19]

Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15