1 Conventional password systems are an extremely unsuitable protection of your information

(1)

iSM-Institut für System-Management GmbH

Oldendorfer Str. 12 * D18147 Rostock * Germany Tel: +49 (0) 381 37 57 30 Fax: +49 (0) 381 37 57 329

E-Mail: [email protected] Web: www.secu-sys.com 1

-Binary authentication in the

bi-

Cube

®

Identity Server by

Secu-Token

1 Conventional password systems are an extremely unsuitable

protection of your information

The majority of the systems with a permission administration does still trust today in passwords in order to identify a user.

1.1 Sufficient well-known problems of the password systems

Static passwords are: • Insecure

Users have not to note a more and more increasing number of passwords. That leads tendentiously to simplifications, simplest derivatives from a “favourite password”, unprotected password lists and to smallest to no optional changing intervals.

• Valuable

A majority of the hotline inquiries refer on problems with passwords. • Complex and unmanageable

If co-workers are dismissed, normally it is unknown how many passwords they have known. If this leaving employee was even an administrator or he was easy-going in handling with passwords, then a huge plenty of passwords have to be changed and rolled out within a very short period of time.

• THE gateway.

Hackers have still overcome each static password protection up to now. First they try to guess passwords, then they try out with different tools, passwords are spied out via the network or at the same time the database is attacked. If all that is not successful the user is asked for his password by e-mail

1.2 Analyst’s - Voice

password protection: Economical alternatives are searched for

Analysts of the Meta Group USA judge passwords as an unsuitable protection of networks. Passwords are ineffective, both because of organisational lacks and due to errors of the users. In the opinion of the experts there are no economical alternatives yet, but that should be changed soon.

Many enterprises look more and more for additions or substitutes of passwords, like for example token, smart cards or services based on PKI. According to Earl Perkins, Vice President of the Meta Group the prices have to decrease, so that such solutions could become generally accepted. There are first indications that in the next months this could happen. However, in addition it is necessary that RSA, which still controls the market for identity management with its SecureID loses this dominance.

(2)

As solutions these different technologies - and first of all their combinations - dependent on the application environment should be used, which enable a secured authentication accordant to today’s requirements.

2.1 One-pass-authentication as secured authentication

Relative few procedures are to be arranged in this category. They must correspond to the requirement that the identity of the user is granted with high security. So far only biometric procedures can be numbered to this category.

Even the as so secure recommended digital signature fulfils in some kind of uses only the security level of a password, as for the release of the signature a password is used again. This fact should be considered even with the so-called „Managed PKI “. Also maps or USB token lose their security receivables, if they are left unsupervised on the pc.

2.2 Dual authentication as secured authentication

The two-pass-Authentication combines the securities of two particulars processes and thereby in most cases sufficient security level is reached.

The binary authentication is therefore increasingly necessary, in order to achieve a secured identification of a user. It is assumed that the user passes two independent information that prove his identity in each case. This can be:

1. Password (PIN) / Certificate 2. Password / Security-Token 3. User-ID / Biometric-ID

In many cases enterprises have made arrangements for the middle- or long term deployment of a PKI in their ICT-strategy. Up to the introduction of a PKI in the whole enterprise and application environment, one of the other variants of the binary authentication can be used.

(3)

-2.3

Security tokens as IPM integrated solution with a high security level

The IPM system of the iSM contains a security-token, which allows a flexible application framework depending on requirements of security and comfort.

The possibilities of application type and variants of the security token allow an optimal adjustment to the category of the users.

With password test

Security level Note Software-Token

portably

X Middle Moving user

With device relationship

X High For fixed workplaces on USB-Token

With expiration date X Middle For temporary permissions

With integrated Bio-Template

Not necessary Very high Can be combined with the first three types of use.

The category of use is set up referring to the person during the generation.

The Secu-Token can be generated either portably or device-bounded and then provided to the user. He can then logon to these applications, which have integrated a token evaluation on the Auth-Server. The Secu -Token has a limited lifetime (default 5 min) so that it can be transferred via network in clear text without problems. The length and the multiplicity of contained test information make it unassailably. Example of a generated token:

B379F3A64191FD9D52C06D8C87DE6BEC00E6CF71B38432D3A52D4331C4811ED2BCA42F2E8 7DC8DD346B78438BF1A5C8E1687D14D4DA4A46C8558A66580547C65A5F18BF957803F5F670 0ACC92891A6C434411445B4EF4CDC5A89147AE88BFDC4BC3F5817A93FFFBE

(4)

2.4 Process of the authentication

The authentication is realised typically after the two-pass procedure. First user ID and password are examined at the Auth-Server and then the token is required from the user.

Only then the application will start.

To the user it is turn out in such a way that after entering user ID and password, he has to

dispose the token transmission.

(5)

-2.5

Bio-Token

In order to achieve also with remote employment a very high security level, a so-called Bio-Token can be generated. This token requests before token

generation the biometric authentication of the user. This is realised via an .EXE and is consequently tamper-proof, as the personalised token generator contains the user’s Bio-Template. In the opposite of other solutions a demand of Bio-Templates from the central server as well the transmission of these to the server inclusive the latent risks in

communication is not necessary.

(6)

2.6 Connection of Secu-Token or Bio-Token to a USB-Device

In the memory-stick a personalised Secu-Token is stored and bound to this device. It is not possible to copy the token program on a USB-stick and to start it then on another drive to the token program from the note stick to.

3 SMS-Token

The benefit of the iSM Secu-Token is, that the user is not obliged to read off the token from another device and to enter it then, because it can be drawn by drag and drop function into the accordant logon field. However, the condition is the possibility of being able to start the token program on the accordant pc, which can be difficult or impossible e.g. in internet terminals or hotels (USB port available).

In analogy to other products (e.g. RSA) in this case the user can select the SMS-Token in the entry mask. Then the server transfers a 6-digit SMS-Token to the mobile phone of the user. This token has to be entered to the entry mask by the user and therewith the dual authentication is realised.

Consequently all contingencies of authentication are secured. The Secu-Token is a flexible and at the same time cost saving solution.

(7)

-3.1

System architecture of SMS authentication

The following functions figure for the SMS authentication:

1. The Auth-Server administers the user data and possible user permissions in a centralised data base. 2. In the first step of authentication the user applies to the web-authenticator with user-ID and

password.

3. This web-authenticator checks the account in a centralised data base and provides the selecting mask and the entry mask for the second step of authentication.

4. The user has to decide for the SMS-Authentication, because he is not able to use his token (e.g. in the internet café).

5. The web-authenticator determines the the mobile phone number of the user within the data abs and transfers the SMS data via SMS –Token (one-time password) to the SMS Server.

6. This sends a SMS to the user.

7. The user enters the SMS-Token into web-authenticator.

8. This checks the validity of the SMS-Token and starts the link (with user-ID as parameter) to the customer’s application, which should be protected by the dual authentication.

The SMS-Token can be used for only one time and his validity is limited temporarily (can be set).

3.2 Technical installation requirements

For a simple installation the following components are necessary:

1. a server with the required admin clients for the administration of user data and a data base (perhaps a runtime for reasons of economy) as well as the required web components (IIS, .NET-Framework) 2. a Linux-PC including the Siemens radio module MC55-T or TC63T2 / TC63USB incl. aerial

DB Oracle, DB2, SQL-Server SMS Server (Linux-PC) request of customer’s application via a link Auth-Server with

user data

( mobile phone number)

MS-IIS with web- Auth-function

(8)

4 Centralised Token-Management

The deployment decision for a security solution is determined next to the security effect and costs also by the manageability. If a procedure is complicated and complex in use and administration,

Wenn ein Verfahren kompliziert und damit aufwendig in der Bedienung und der Verwaltung ist, very high deployment barriers can arise.

The wide integration into the central IPM-solution enables the definition of rules, which automate the token management in a high degree.

4.1 Automatic setting of security-classification

Within the application it can be controlled, if the user needs an additional token authentication or not. If the application is widely integrated in ZUM, this grouping and/or security classification can be bound to the application, to the user or to the role.

The obligation to use the token can be bound by the definition of security classification of the user or the application.

A role with high potential of danger can be used only if the owner of the role has a Secu-Token.

4.2 Use of existing Bio-Templates

Analogue an already taken up fingerprint, which is used e.g. in the SSO, can be integrated into the token smoothly, without a further fingerprint take-up by the user.

(9)

-4.3

User categories and their automatic connection to authentication

procedures

The accordant kind of use, the technology and their integration into a complete security concept act in accordance with demand of protection of the provided applications/ data and the category of use. These are for example user groups with different requirements:

As the categories can be derived either directly from the attributes of a user (e.g. organisational unit, function etc.) or his roles, also rules for the automatic assignment of a required or adequate authentication procedure can be defined.

5 Deployment recommendation

Considering facts like costs, security and function this procedure can be recommended absolutely. A very high effect can be gained, when the Secu-Token is deployed there where the centralised user management of the bi-Cube product family is in use.

comfort mobility broad of use of data demand of protection of available data passable cost factors due to number of users board of directors

high high high high high

external agents middle low low high low

outside work middle high middle middle low

indoor service middle low middle middle low

administrators middle middle high high middle

external service provider