Guidance on Multi-factor Authentication

Gui

danc

e on

Mul

ti-fa

ctor

Aut

hent

icat

ion

June

200

6

�

Guidance on Multi-factor Authentication

State Services CommissionJune 2006Version 1.0ISBN 0-478-24466-5© Crown copyright 2006

�

�

AcknowledgementsThe State Services Commission gratefully acknowledges the contribution of time and expertise from all those involved in developing this Guidance.

CopyrightThis Guidance is subject to Crown copyright. The material may be used, copied and re-distributed free of charge in any format or media, provided that the source and copyright status is acknowledged (i.e. this material was produced by the State Services Commission © Crown copyright �006).

Accessing advice on this GuidanceAdvice on this Guidance can be obtained from:

e-GIF OperationsState Services Commission

Postal: PO Box ��9, WELLINGTONPhone: 04 495 6600Fax: 04 495 6669Email: e-gif@ssc.govt.nzWeb: www.e.govt.nz

4

Executive SummaryThis Guidance on Multi-factor Authentication examines the issues with the use of multi-factor authentication keys. It does not prescribe the use of any particular authentication key, as it has been developed as an information resource to supplement the Authentication Keys Strengths Standard [�], one of the New Zealand E-government Interoperability Framework (NZ e-GIF) authentication standards [�]. This Guidance is intended for anyone looking for further information on selecting multi-factor authentication keys, especially those with responsibility for information technology systems and their security.

Authentication consists of two processes:

• evidence of identity• ongoing confirmation of identity, for example using a username and

password to logon.

This Guidance focuses on the second process above.

Authentication keys are called multi-factor when they use more than one of the factors of authentication: something you know, have or are – where “are” in this context means a physical or behavioural characteristic of a person. The most common example of a single-factor authentication key is a password – something you know. Sometimes passwords, by themselves, do not provide sufficientconfidenceintheidentityoftransactingparties,andstrongerformsofauthentication, usually involving multi-factor authentication keys, are required.

Multi-factor authentication can improve security. However, this usually comes with an increase in cost and system complexity. For these reasons, the authentication key must be selected based on the risks to be addressed. Authentication key requirements are set out in the NZ e-GIF authentication standards. This Guidance assists with the selection of an authentication key by discussing the various merits of the following authentication keys:

• passwords • hardware tokens• software tokens • one-time passwords• biometrics.

These authentication keys represent the major ones used today and are the ones identified in the NZ e-GIF Authentication Key Strengths Standard [�]. Passwords are common single-factor authentication keys and are included here for comparison.

5

Selection of an appropriate authentication key is only one aspect of securing onlineservices.Agencieswillalsoneedtouseothermeasures(brieflyreferredto in Section �.�). In particular, agencies must comply with the manual Security in the Government Sector [�] and the New Zealand Government Information Technology Security Manual – NZSIT 400 [4].

A brief summary of each of the authentication keys discussed in this Guidance is included below. This Guidance assumes that one-time passwords, software tokens and hardware tokens are used in conjunction with a password or biometric, to deliver multi-factor authentication. This is normally (but not always) the case with these authentication keys.

PasswordsThe use of passwords for authentication is widely established; both implementers and customers accept them, with the various issues being well documented and understood. However, password systems are susceptible to many attacks and attacks against passwords are generally serious as they usually recover the password. Additional protections for the communication channel can be used to protect the password, but this still does not prevent all attacks.

Manysecurityexpertsnowregardpasswords,bythemselves,asinsufficientforonline authentication for anything other than low risk services. The NZ e-GIF authentication standards take this approach.

Hardware tokensThis Guidance regards hardware tokens as being specialised hardware devices that protect secrets (normally cryptographic keys) and perform cryptographic operations. The cryptographic operations support authentication of both parties and the protection of the communication channel used for the authentication exchange.

Drawbacks of hardware tokens, compared to other authentication keys, include:

• increased cost, implementation and deployment complexity• reduced ease of use for customers.

6

Software tokensSoftware tokens are essentially software implementations of hardware tokens and so share many of the advantages of hardware tokens. As with hardware tokens, software tokens support authentication of both parties and protection of the communication channel used for the authentication exchange.

The major issues with software tokens are:

• the potential for them to be copied• they may be copied without the owner’s knowledge.

This results from the lack of a physical container protecting the secrets. The main advantage, compared to hardware tokens, is the lower cost.

One-time passwordsOne-time password systems rely on a series of passwords generated using special algorithms. Each password of the series is called a one-time password as it is distinct from the others generated and can only be used once. A wide variety of one-time password systems exist that provide varying protection against attacks. Common advantages for one-time passwords systems are:

• they are easy for customers to use• they have relatively low implementation costs and complexity, when

compared to software and hardware tokens.

Some of the attacks used against traditional passwords are mitigated with one-time passwords. For example, with discovery attacks (attacks that recover passwords such as phishing attacks):

• any (one-time) password obtained may be used only once• with some systems, the (one-time) password obtained can be used only

within a very limited time frame.

Authenticationoftheverifierisnotusuallysupported,whichcanbeexploitedinattacks. The exposure to copying attacks (where the one-time password device itself is copied) depends on the actual solution used.

BiometricsBiometrics are well suited to local access control (as with passports in border control) but not as well suited to remote authentication. One of the main reasons isthatbiometricdataispersonaldataandsignificantprivacyissuesarisewiththecollection, storage and use of such information. With remote authentication, this means special care must be taken to protect transmitted biometric data.

�

Table of ContentsAcknowledgements ............................................................................................ �Copyright ........................................................................................................... �Accessing advice on this Guidance .................................................................... �Executive Summary ........................................................................................... 4 Passwords ..................................................................................................... 5 Hardware tokens ........................................................................................... 5 Software tokens ............................................................................................ 6 One-time passwords ..................................................................................... 6 Biometrics .................................................................................................... 6Introduction ........................................................................................................ 8 Purpose ......................................................................................................... 8 Audience ....................................................................................................... 8 Relationship to the authentication standards ................................................ 8 Document structure ...................................................................................... 8 Background .................................................................................................. 9The Factors of Authentication .......................................................................... �� Multi-factorauthenticationandsecurity:afirstlook ................................. ��Authentication Attacks and Countermeasures ................................................. �5 Authentication attacks ................................................................................ �5 Countermeasures ........................................................................................ ��Detailed Discussion of Authentication Keys ................................................... �8 Passwords ................................................................................................... �8 Hardware tokens ......................................................................................... �0 Software tokens .......................................................................................... �� One-time passwords ................................................................................... �5 Biometrics .................................................................................................. �� Remarks ...................................................................................................... �0Multi-factor Authentication Solution Selection Issues .................................... ��Government Use of Multi-factor Authentication ............................................. ��The Government Logon Service ...................................................................... �5Trends ............................................................................................................... ��Glossary ........................................................................................................... �9Referenced documents ..................................................................................... 4�Latest revisions ................................................................................................ 45Review of Guidance ......................................................................................... 45Appendix A. Technical Protection References ................................................ 46

8

IntroductionPurposeThis Guidance on Multi-factor Authentication examines the issues surrounding the use of multi-factor authentication keys by government agencies. It does not prescribe the use of any particular authentication key. Requirements for authentication keys can be found in the New Zealand E-government Interoperability Framework (NZ e-GIF) [�] authentication standards, which are discussed further below.

AudienceThis Guidance has been written for those whose responsibilities include the development and management of Information Technology (IT) systems, especially relating to the delivery of secured online services. This includes agency ITcustodianssuchaschiefinformationofficers,chieftechnologyofficers,andIT managers and administrators. Technical analysts, systems architects and developers and IT security mangers and administrators, should also read this Guidance, in particular the references for more detailed information included in Appendix A.

Relationship to the authentication standardsThe NZ e-GIF authentication standards provide detailed guidance for agencies to follow when designing their authentication systems. These standards are introduced in the Guide to Authentication Standards for Online Services [5]. In particular, the Authentication Key Strengths Standard [�] requires a two-factor authentication key to be used for services in the Moderate or High service risk categories. This Guidance does not give recommendations. It has been developed as an information resource to supplement the Authentication Key Strengths Standard.

Document structureBackground material is covered next in this section. The following section discusses the three factors of authentication (one of the major ways of categorising authentication methods) and introduces multi-factor authentication. The authentication attacks considered in this Guidance are then discussed, with other countermeasuresbrieflytouchedon.Themainsectionthenlooksateachoftheauthentication keys (listed below) outlining their advantages and disadvantages and the attacks they counter. This is followed with a list of some issues that should be considered when selecting a multi-factor authentication key. Brief details on the use of multi-factor authentication keys by governments for the delivery of online services is covered next before the Government Logon Service that is

9

being developed by the New Zealand Government’s Authentication Programme isintroduced.Thefinalsectionlooksattrendsaffectingtheuseofmulti-factorauthentication. Most terms and acronyms are included in the Glossary.

BackgroundTo meet the Networked State Services Development Goal [6], agencies will need to provide online services that have higher levels of risk. This will require the use of higher strength authentication keys.

Authenticationistheprocessofestablishing,totherequiredlevelofconfidence,the identity of one or more parties to a transaction. This consists of two processes:

• evidence of identity• ongoing confirmation of identity, for example using a username and

password to logon.

The NZ e-GIF authentication standards cover both of these processes.

This Guidance focuses on the second process above. In particular, this Guidance is interested in the case where someone makes an identity claim and provides some evidence to support this claim, by using their authentication key to provide some level of assurance that they are who they are who they say they are.

�0

The authentication keys discussed in this Guidance are:

�. passwords �. hardware tokens�. software tokens 4. one-time passwords 5. biometrics. These authentication keys represent the major ones used today and are the ones identifiedintheNZe-GIFauthenticationstandards.Figure1depictsexamplesof these authentication keys.

The focus of this Guidance is the electronic authentication of people across an unprotected channel, primarily the Internet. In this Guidance, authentication involves two parties:

• customer – a person who claims some identity and who undergoes the authentication process

• verifier – an entity that receives and verifies customers’ online identityclaims.

In some cases, the customer will also require confidence in the identity ofthe verifier. When both parties authenticate to one another, this is calledmutual authentication. Usually, the same or very similar methods are used for mutual authentication. Authentication keys differ in their support of mutual authentication.

Figure 1 – Some examples of authentication keys

(2)(1)

(3) (4) (5)

��

An authentication exchange is the exchange of information required for the authentication process. The online authentication exchange occurs between the customerandtheverifieroveranunprotectedcommunicationchannel,suchasthe Internet. Such a setting is depicted in Figure �.

In many situations protections for the communication channel are also used. An example of this is the TLS protocol is often used to protect services delivered online using web browsers. Although this Guidance will refer to such protections, it does not include an analysis of the various protocols.

Figure 2 – The authentication exchange setting

Communication channelVerifier Custommer

��

The Factors of AuthenticationThe ways in which someone may be authenticated fall into three categories, based on what are known as the factors of authentication: something you know, have or are. These factors, and how they may be compromised, are described in Table � below.

Table 1 – Descriptions of the factors of authentication

Factor Something you…

Examples Attack method

Know Common examples are passwords and collections of personal information (e.g. mother’s maiden name). Personal information is not necessarily secret, but is assumed to be unknown by anyone else. NOTE – Mother’s maiden name is now regarded as providing little confidence in the claimed identity.

An attacker must discover the known information.

Have Signet rings and passports are examples. Such objects are collectively called tokens. Some tokens perform sophisticated authentication functions, such as providing protected storage for cryptographic keys and performing cryptographic operations. Tokens for electronic authentication come in software or hardware forms.

An attacker must obtain or copy the token.

Are This is either a physical (as with fingerprints) or behavioural (as with typing patterns) characteristic of a person. Authentication methods based on this factor are commonly called biometrics.

An attacker must replicate what you are.

Note that authentication methods based on personal information suffer from a number of problems:

• There is not much information that can be used and it is either:– static and cannot be changed (as with the mother’s maiden name of a

person), or– needs to be kept up to date by the customer (for example, if a customer

uses their pet’s name, then this may change and must be updated by the customer).

��

• The value of such information for authentication is degraded as more organisations collect it.

• The information can often be easily discovered by an attacker through research or observation.

Note also that agencies that collect, use and disclose personal information must ensure that what they do complies with the Privacy Act 1993 [�]. This Guidance does not consider authentication keys based on collections of personal information further.

Multi-factor authentication and security: a first lookMulti-factorauthenticationisdefinedasthecombineduseofmorethanoneofthefactors of authentication from Table �. As there are three factors of authentication, there are three possibilities:

• Single-factor authentication – This uses only one of the three factors of authentication. An example is a password (something you know).

• Two-factor authentication – This uses two of the three factors of authentication. Accessing your account through an ATM is based on two factors of authentication: the PIN (something you know) and the ATM card (something you have).

• Three-factor authentication – This uses all three of the factors of authentication. For example, to access a secure site you might need to pass a guard who checks your face against a stored image (something you are), swipe an access card (something you have), and enter a four-digit code (something you know).

Multi-factor authentication is either two-factor or three-factor. Note that using two types of the same factor is not multi-factor authentication. For example, a password and personal information are both what you know, so using them together would still be single-factor authentication.

The strength of authentication keys can vary even within a factor category. Mother’s maiden name, a four-digit code and a random eight-character alphanumeric password are all examples of authentication keys based on what you know, but they each provide different protection against discovery attacks. Consequently, the security of the authentication process is affected by the actual solution used. However, it is generally held that multi-factor authentication improves security. In general, for the examples above:

• Tousethepassword,youneedtofindoutthepassword.• TousetheATMcard,youneedtofindoutthePINandstealorcopythe

ATM card.

�4

• Togetintothesecurebuilding,youneedtostealorcopyanaccesscard,findout the access code and have the guard accept your face against one of those on their system.

So the amount of work for an attacker generally increases with the number of factors of authentication used. However, it could be the case that the security of a three-factor authentication method is comparable to, or even worse than, a single-factor method. With the secure site example, maybe the guard can be bribed, new access cards are easy to obtain, and the initial access code is always four zeros. Nevertheless, there is certainly more scope for improving security with multi-factor authentication as compared to single-factor authentication – it comes down to ensuring that the potential strength for an implementation is actually achieved.

Another issue is that the factors of authentication relied upon can change. This is the case when someone writes down his or her password. The password changes from being something you know to something you have. In this case it maybeeasiertofindthantoguessthepassword.Thisproblemtypicallyoccurswith systems that force people to use randomly generated passwords. Random passwords are hard to remember, so people tend to write them down and keep them near their computer for convenience. A password might be found by searching the area around a computer, whereas security for the system probably assumes an attacker has to guess a random password. So when the factors relied upon change, the vulnerabilities of the system (and hence the potential attacks against it) do too.

As discussed above, actual implementations will vary in the protection they provide. Other weaknesses, not related to the authentication process, also need to be addressed. These weaknesses may arise out of such things as poor design, lack of security culture, or simple human error. Consider the secure site example: ifthereisabackdoor(forexample,afireescapeexit)thatcanbeusedforentry,the attacker may be able to bypass all authentication checks. In this case it would not matter that you had a diligent guard, a well-controlled access card system and good access code practices. In fact, the authentication system will amount to worse than nothing if there are other ways in, because of the false sense of security it gives.

�5

Authentication Attacks and CountermeasuresThis section introduces the authentication attacks considered within this Guidance andbrieflydiscussesothercountermeasures.

Authentication attacksTable � below lists generic attacks against authentication keys and the authentication exchange. Attacks against the initial enrolment process, management of authentication keys, etc., are not considered in this Guidance. The list of attacks in Table � is not limited to the authentication key, as some authentication keys can also be used for protecting the communication channel.

It is important to note that Table � is not intended to be complete, but does cover the major attacks the authentication keys considered here can counter. Readers mayprefertojustbrieflyreviewthelistedattacksnowandreferbacktoTable2asrequired.The listedattacksarenotdistinct, forexampleshouldersurfingattacks are a type of social engineering attack.

Table 2 – Authentication attacks

Attack DescriptionCustomer fraud attacks

Where the customer deliberately compromises his or her authentication key or computing environment to enable them to deny subsequent authentication events.

Eavesdropper attacks

Where an attacker obtains information from an authentication exchange and recovers data, such as authentication key values, which then may be used to authenticate.

Insider attacks Where verifiers or systems managers deliberately compromise the authentication system or steal authentication keys or related data.

Key logger attacks Malicious code or hardware attacks that capture keystrokes of a customer with the intention of obtaining any password typed in by the customer or other manually entered authentication key data. Screen logger attacks are variants that capture keystrokes along with display information to circumvent screen-based security protections.

�6

Attack DescriptionMalicious code attacks

Attacks that are generally aimed at the customer’s computing environment. They vary in their sophistication from simple key loggers to advanced Trojan programs that can gain control of the customer’s computer. Malicious code attacks may also be aimed at verifier systems.

Man-in-the-middle attacks

Where an attacker inserts himself between the customer and the verifier in an authentication exchange. The attacker attempts to authenticate by posing as the customer to the verifier and the verifier to the customer.

Password discovery attacks

This covers a variety of attacks, such as brute force, common password and dictionary attacks, which aim to determine a password. The attacker may try to guess a specific customer’s password, try a few commonly used passwords (such as “Pa$$word”) against all customers, or use a pre-composed list of passwords to match against the password file (if they can recover it), in their attempt to discover a legitimate password.

Phishing attacks Social engineering attacks that use forged web pages, emails, or other electronic communications to convince the customer to reveal their password or other sensitive information to the attacker.

Replay attacks Where the attacker records the data of a successful authentication and replays this information to attempt to falsely authenticate to the verifier.

Session hijacking attacks

Where the attacker takes over (hijacks) a session following successful authentication.

Shoulder-surfing attacks

Social engineering attacks specific to password systems where the attacker covertly observes the password when the customer enters it.

Social engineering attacks

Attacks that are aimed at obtaining authentication keys or data by fooling the customer into using an insecure authentication protocol, or into loading malicious code onto the customer’s computer. Attacks may also be aimed at the verification process, for example by trying to trick help desk staff into accepting a false story.

Verifier impersonation attacks

Where the attacker impersonates the verifier to the customer to obtain authentication keys or data, which then may be used to authenticate falsely to the verifier.

��

CountermeasuresIt is possible to implement a range of countermeasures to the authentication attacks described above. While the choice of authentication key is important, theuseof an authenticationkey alone is not sufficient.Othermeasures, bothtechnical and non-technical, need to be in place:

• Some relate to managing the authentication key – including policies and procedures for distribution, lifecycle and storage protection, etc.

• Others are completely separate of authentication key considerations – such as anomaly detection, customer education, enrolment procedures, etc.

Such countermeasures are important, but are not discussed in detail in this Guidance.

Government agencies are required to comply with Security in the Government Sector [�]. Annex A of that manual refers to the minimum standards for Internet security. Further standards and references include [4, 8-�4]. Agencies should also refer to the NZ e-GIF authentication standards [�] for further requirements. General issues relating to the selection of multi-factor authentication keys are covered later in this Guidance.

How countermeasures relate to the authentication key can depend on the authentication key used. For example, the cryptographic keys of software and hardware tokens can be used to support additional protections, whereas passwords do not offer such support.

�8

Detailed Discussion of Authentication KeysThis section looks at the advantages and disadvantages of each of the authentication keyslistedearlierandconsiderstheattacksthatspecificauthenticationkeyshelpto counter. Note that hardware tokens, software tokens and one-time passwords are usually used in conjunction with a password and/or a biometric and this is assumed to be the case in this Guidance. Such combinations result in at least two-factorauthentication.Authenticationkeys, includingonesnot specificallycovered by this Guidance, are discussed in [�, 4, �5-��].

Passwords Description

Apasswordisasecretthatissharedbytheverifierandthecustomer.Itisusualfor the verifier to keep the passwords protected on their system by storingthem in encrypted or hashed form and in this form they may still be used in the authenticationprocess.So theverifierusuallyonlyhasencodedcopiesof thepasswords. Passwords are normally made up from the characters available on a standard keyboard. Other options exist, such as visual passwords, but these are not widely used.

Advantages

�. Password based online authentication is easy to deploy, as special software does not need to be installed on the customer’s computer.

�. Password systems are familiar to customers, systems administrators and managers. The security and management issues are well understood.

�. Passwords can (and should) be encrypted or hashed when stored on the verifier’ssystem.Thereisnoneedforthemtoeverresideontheverifier’ssystem in the clear (not encrypted or hashed).

Disadvantages

1.People have difficulty recalling strong passwords and often forget them,adding to management overheads.

�. People will use the same or similar passwords across different systems without regard for the risks involved: the systems may use different levels of protection for the passwords.

�. People write down their passwords and leave the written copy in places that are accessible to others.

4. People use passwords that are easy to remember, which often means they are also easy to guess (and so are weak passwords).

�9

5. People share their passwords. The sharing of a password does not stop the password owners from continuing to use their password. Those with whom the password is shared have access until the password is changed.

6. An attacker may obtain a customer’s password without the customer being alerted. It is possible to implement customer self-audit functions (where the customer checks recent activity against their account) but the customer will not necessarily use these.

Attacks mitigated

The reality is that passwords alone do not mitigate any of the attacks listed in Table �. Provided customers follow good password practices, password discovery, phishing, and shoulder surfing attacks can bemitigated.However,anecdotal evidence shows that a significant proportion of customers will notfollow good password practices. Using communication channel protections can mitigate eavesdropper, replay and session hijacking attacks.

Attacks not mitigated

Some of the possible attacks are listed below. It is important to note that most attacks result in the attacker obtaining a copy of the password, a severe breach of the authentication system.

1.Customerfraud–Theoccurrenceofsuchattacksisdifficulttodetermine,but invariably occurs to some degree. Most banks currently refund customers for disputed Internet banking transactions claims, some of which may be fraudulent.

2.Insiderattacks–Theverifierorsystemsmanagerswhohaveaccesstothepassword file may conduct such attacks. Even when the passwords arestored in encrypted or hashed form, passwords may still be recovered by conductingadictionaryattackonthesefiles.

�. Keyboard logging attacks – In the form of malicious code attacks, these have been used in New Zealand (see the section on trends). Hardware based key loggers have been used elsewhere, but are less common.

4. Man-in-the-middle attacks – These attacks require the attacker to intercept the authentication exchange. The use of communication channel protection increasesthedifficultyofconductingman-in-the-middleattacks.

5. Social engineering attacks – Examples of these attacks against passwords include shoulder-surfing and phishing attacks. Phishing attacks havebecome popular (see the section on trends) and such attacks can be mounted remotelyandautomated.Shoulder-surfingattackshavebeenadaptedtotakeadvantage of modern technology; these attacks are now being conducted via the use of hidden video devices.

�0

6.Verifier impersonationattacks–Attacksarepossibleevenwhenstandardcommunication channel protections are used (for example, with TLS, manually entering the URL and checking for the padlock does not entirely preventsuchattacks).Verifierimpersonationhasbeenusedinanumberofphishing attacks.

Summary

Passwordshavehighcustomerandverifieracceptance,andsuchauthenticationsystems are well understood. The problems with passwords result from them:

• beingbasedonasharedsecret–tousemultipleverifiersyouneedtohaveadifferentoneforeachverifier

• relying on the customer’s memory and adherence to good password practices – if the password is use infrequently it may be forgotten and people do not generally follow good password practices.

Attacks usually work by obtaining the password. This is a severe breach of security as the attacker is then able to operate as the customer until the breach is discovered.

Hardware tokens Description

In this Guidance, hardware tokens are viewed as being specialised hardware devices (with integrated chips) that protect cryptographic keys and perform cryptographic operations within this protected boundary. Here, it is assumed that the use of the hardware token requires the entry of a password or biometric so that the hardware token provides at least two-factor authentication.

NOTE – Hardware one-time password devices exist and share some of the properties of hardware tokens, see below.

There are many different hardware tokens, but the most important differences arise from the security functions supported and the protections provided for the cryptographic keys and operations. These protections are referred to as tamper resistance. Protections may include:

• chip design that aims to thwart internal analysis• theuseofgluesthatarestrongerthanthechip,sothechipbreaksfirstwhen

anyone tries to separate is from its casing• measures to prevent password experimentation• features to clear the memory or self-destruct if internal analysis attacks are

detected.

��

The cryptographic functions of hardware tokens support strong mutual authenticationbetween thecustomerand theverifier.Hardware tokenscanbeused for one-way authentication, but the analysis below assumes that mutual authenticationisused;otherwiseverifierimpersonationandman-in-the-middleattacks are not mitigated.

Advantages

�. Hardware tokens are physical objects, so a customer should notice if it is stolen.

�. As the hardware device is used in conjunction with a password and/or biometric, the authentication solution is at least two-factor and possession of the device alone is not enough to authenticate.

�. Some hardware tokens support the on-token generation of cryptographic keys and, if public key cryptography is used, such secrets can remain within the protected boundary of the token at all times.

NOTE – It is important that sound generation methods are used, as cryptographic keys must not be predictable.

4. Hardware tokens are comparatively well understood in terms of their tamper resistance. This is due to active research in this area over the last �0-�0 years, which has led to design improvements. Ongoing analysis will lead to furtherimprovements.Thisresearchprovidesconfidencethatdevelopmentsin hardware token security are staying ahead of developments in attacks, at least in terms of tamper resistance. Similar research is occuring for hardware token APIs.

5. Most hardware tokens come with warranties covering consumers against malfunction.

6. Some tokens require a special reader. Although this adds to costs it does improve security. This is because the password or biometric can be entered through the reader, bypassing the customer’s computer, where it is exposed to key logger attacks.

Disadvantages

�. Hardware tokens require special software to be installed on the customer’s computer.

�. Some hardware tokens require special external hardware readers (the advantages of these are already discussed above), which increases the overall cost. This is being addressed as some computers now come with in-built readers and other form factors, such as USB tokens, that do not require special readers are becoming more widely available.

��

3.Verifierswillneedtoinstallspecialisedsoftwareand/orhardware.4. Management for cryptographic keys, readers, tokens and associated

passwords or biometrics must be implemented. These tasks complex tasks, but are critical for security.

5.Researchshowsthatpeoplesometimeshavedifficultyusingthefunctionsofhardware tokens. Customer training would be required.

6. If the hardware token is lost or misplaced by the customer, or it is broken, then the customer is unable to authenticate until it can be replaced.

�. The token can be shared. This is easier when it is used with a password. Unlike the case for single-factor passwords, the legitimate owner must also give up their ability to authenticate, which can act as a deterrent to sharing.

8. Some hardware tokens have internal batteries, which limits their lifetime.

NOTE – Such hardware tokens may come with additional protections based on the internal battery.

Attacks mitigated

As with passwords, using communication channel protections can mitigate eavesdropper, replay and session hijacking attacks. However, unlike passwords, the functions of the hardware token can be employed in these protections.

It is possible to mitigate almost all of the listed attacks using the hardware token functions, except those noted directly below. Although it would still be possible to mount a customer fraud attack, tamper-resistant hardware tokens are designed to defend against attacks where it is assumed that the attacker has control of the token. Customer fraud attacks are therefore less likely to succeed with hardware tokens than with the other authentication keys.

Attacks not mitigated

�. Malicious code attacks – These attacks come in many forms. Hardware tokens are susceptible to malicious code attacks that can prompt the token for an authentication request. Even when the hardware token is protected with a password or biometric, the attackers code can either gather this data on entry or wait until the customer activates their token. To defend against the second attack, some hardware tokens require activation with a password of biometric at each use. However, such measures have poor customer acceptance. Although no authentication key provides complete protection against malicious code attacks, it is important to note that hardware tokens still provide good protection for the cryptographic keys: generally it is not feasible for them to be recovered by an attacker – effectively this means while in theory it is possible to extract the cryptographic keys, this would requiresignificantknowledge,equipmentand/ortimeresources.

��

�. Insider attacks – Authorised insiders abusing their privileges may be able to obtain stored cryptographic keys. Additional protections need to be in place to prevent such attacks.

NOTE – Cryptographic keys generated and stored solely on the hardware token and not susceptible to this type of attack.

3.Specificcryptosystemortokenattacks–Attacksagainstcryptosystemsandtokens are occasionally discovered. Public attacks have so far come from the research community and have been addressed before any major security issues arise.

Summary

Hardware tokens are generally considered to support stronger security, but this comes with an increase in cost. Nevertheless, systems requiring a high level of security will invariably be based on hardware tokens, as the reduction of risks in thiscasejustifiesthecosts.

Software tokens Description

Software tokens are essentially software implementations of hardware tokens: pieces of software that protect cryptographic keys and perform cryptographic operations. Most vendors of hardware tokens also provide software versions. The major advantage is the lower cost. Again, it is assumed that the functions supporting mutual authentication are used and the software token is protected with a password and/or biometric so that it supports at least two-factor authentication.

Advantages

�. Software tokens are portable in the limited sense that they may be copied onto other platforms provided those platforms have had the necessary supporting software installed.

�. Distribution can be simpler when compared with hardware tokens, but still needs to be adequately controlled and administered to ensure security is not degraded. For example, software tokens could be encrypted and emailed. Then the system needs to support the recovery of the software token by the intended recipient.

Disadvantages

�. As with hardware tokens, some training would be required for customers to correctly use and protect the software token.

�. Software would need to be installed on the customer’s computer.

�4

�. Software tokens are more easily copied than hardware tokens. If an attacker can obtain a copy of the customer’s activation data (password and/or biometric), then the attacker may fraudulently authenticate. The customer may not even be alerted to the loss of their authentication key. Another option for the attacker is to wait until the software token is activated and copy the cryptographic keys while in use. The attacker may even be able toextracttheactivationdatafromthesoftwaretoken’sfilesorusethesetoconduct a brute force attack on a copied token.

4. The owner can share a copy of their software token and activation data (again easier with passwords) without losing their ability to authenticate. The supporting software also needs to be available to those who take a copy.

5.Verifierswillneedtoinstallspecialsoftwareand/orhardware,andimplementmanagement controls for the cryptographic keys and software tokens.

Attacks

In terms of attacks, software tokens are very similar in their capabilities to hardware tokens. The distinctions arise from the fact that a software token may be copied and/or the cryptographic keys gained without alerting the customer to the loss. Software tokens offer significantly lower capabilities in terms ofprotection for the cryptographic keys. A much wider variety of software attacks can be remotely launched and automated, whereas attacks on hardware tokens usually require gaining physical control of the token.

As software tokens are more susceptible to copying attacks, customer claims of compromise hold more weight; making customer fraud attacks more viable than with hardware tokens.

Summary

The main advantage of software tokens is the ability to obtain similar functionality to hardware tokens at a lower cost. Management and distribution overheads can be reduced. However, distribution procedures still need to be carefully managed to avoid degrading security.

The trade-off for lower costs is the copying attacks that become viable. The environment in which the software token will be used is therefore critical to accessing the risks. For example, using a software token in a controlled hardened computing environment does not pose the same sort of risk as using one in a cybercafé.

�5

One-time passwords Description

One-time password systems generate a series of passwords using special algorithms. Each password of the series is called a one-time password, as it can only be used a single time and it is distinct from the other passwords (or at least distinct with very high probability over a given cycle). There are many different one-time password systems available. The comments concerning hardware tokens above also apply to hardware one-time password devices, except those relating to communication channel protections. Tamper resistance varies across products and this market is still maturing in its use of tamper resistance features.

Many one-time password methods are based on a static base secret that is shared betweenthecustomerandtheverifier.Theseriesofone-timepasswordsisthengenerated using this base secret, a nonce (a value that is different with each authentication, preventing replay attacks) and a one-way function. These one-time password systems come as two basic variants, depending on whether the nonce is based on:

• a time value – This requires the device to contain a clock and therefore a battery to run the clock. A window exists for which the one-time password can be used (from �0 seconds to a few minutes). Re-synchronisation procedures are employed to handle clock drift.

• a counter – The counter is incremented at each use.Solutions also exist that use a combination of these two variants.

Other systems are based on a collection of passwords shared between the customerandverifier thataregeneratedanddistributedbytheverifier. In thiscase the collection itself is the base secret. Others use challenge/response with a shared or known function. The function may be simply a printed table or a more sophisticated system based on a one-way function. There is a range of one-time password systems available and the above is only a brief introduction.

Advantages

�. One-time password systems can be easy to deploy and may not require any special software to be installed on the customer’s computer.

NOTE – Some use one-time passwords generated on a hardware device that is communicated directly to the computer, say through a USB port. This option requires software to be installed.

�. One-time password systems are generally acceptable to customers, due to their similarity to password systems.

�6

�. One-time password clock-based devices and challenge/response systems can be used across multiple systems (whereas counter-based solutions cannot without complicated re-synchronisation). It is necessary that these are trusted systems, as each has the capability to impersonate the customer to the others. In practice, clock-based systems may also require time synchronisation to work effectively.

4. With hardware one-time password devices and printed lists, the customer is likely to notice the loss if they are stolen.

Disadvantages

1.Theverifierwillneedspecialsoftwareand/orhardware.Protectedstorageand management of the base secrets is required.

�. A disadvantage with clock-based one-time passwords used across multiple systems is that there is a window of exposure: when a one-time password is used it can be used with any of the other systems if an attacker obtains it. Shorter windows reduce the scope of such attacks. Also, these attacks may be countered by protecting the communication channel.

�. Most hardware one-time password devices do not provide the same level of tamper resistance, and thus protection for the base secret, as hardware tokens do. This may change in the future as the hardware one-time password device market matures.

4. Systems based on shared printed tables, sometimes called bingo cards, have the same problems as written-down passwords: they may be copied or discovered and used without the customer’s knowledge. Loss of the authentication key itself is a much more severe breach of security than the loss of any single one-time password.

NOTE – Shared tables exist that conceal the numbers under a coating, called scratchy cards, with the customer removing the coating to reveal each one-time password. These cards defend against copying attacks. They may still be stolen and used, although the customer would be expected to notice the loss of their card.

5. With authentication key sharing, the extent of the problem here would relate to how easy it is to copy. If copying is easy, then the customer can share their authentication key without losing the ability to authenticate. If copying is not feasible, then this may deter customers from sharing their authentication key, as they must also give up their ability to authenticate.

��

Attack mitigated

One-time passwords in general mitigate replay, eavesdropper, key logger and shoulder-surfingattacks,becauseonceaone-timepasswordisuseditcannotbeused again. One-time passwords used across multiple systems cannot completely mitigate against these attacks without further protection measures being in place. Using communication channel protections mitigates session hijacking attacks.

Attacks not mitigated

Other attacks are not mitigated by one-time passwords themselves. Systems should employ further protections for the communication channel. The scope of customer fraud attacks would depend on the actual product (primarily this relates to the easy of copying and tamper resistance features). An important distinction with passwords is that a phishing attack only gains a single one-time password, which greatly decreases the scope of these attacks when compared to passwords.

Summary

One-time passwords systems are relatively simple to use and deploy. There is a wide variety of systems available that range from bingo cards through to hardware devices that compute the one-time passwords. There is therefore a wide range in their strength against attacks. All one-time password systems need to be used in conjunction with communication channel protections. As mutual authentication isnotsupported,verifierimpersonationattacksarepossible.Thismeansthereissome exposure to the phishing attacks, although the potential for success with such attacks is far more limited than with password systems. The exposure to coping attacks depends on the product.

Biometrics Description

Biometrics rely on physical or behavioural characteristics of a person. The fingerprints, hand geometry, retina pattern, iris pattern, face, voice pattern,written signature dynamics and keyboard typing patterns of a person are just some of the examples. An initial record, called a template, is taken from a person. To authenticate, a biometric reading is taken and matched against their template. Readings and templates are discrete subsets of a person’s original biometric, with the reading being a smaller subset of the template. It is not practical to reverse the process from a reading or template to the original biometric (although it may be possible to construct a copy good enough to fool the authentication system).

�8

As readings will not always be identical (due to environmental or other factors), the matching function must include a tolerance for discrepancies. Usability and security are balanced in any biometric system by adjusting this tolerance, namely by adjusting what are known as the false acceptance rate and the false rejection rate.

Advantages

�. Biometric technologies are sometimes favourably compared with other authentication keys because it is not possible to forget them and they cannot be easily lent.

NOTE – The metaphor “the body is the password” is often used by vendors. However, this is confusing, as passwords and biometrics are based on different factors and have somewhat different properties.

�. Some biometrics are very stable; they do not change a great deal over the lifetime of the individual.

Disadvantages

�. Unlike other authentication keys, biometrics are not based on secrets. Attacks to replicate some biometrics for individuals exist and are relatively low cost [��]. More expensive systems include additional protections against attacks, such as liveness checks that aim to determine if the reading is from a living person.

�. Matching the biometric reading to the record can fail if the biometric is damaged or if the biometric changes. Biometrics vary in their stability and systems can use adaptation. Higher tolerances in the biometric system lead to lower assurance that the customer is who he or she claims to be (as the probability of false acceptance increases).

�. Biometric authentication using an unprotected communication channel is insecure. So, further protections must be in place to secure the communication channel.

4. Loss of biometric data (even from a reading) is a severe breach: not only does it have the same problem as for passwords (the attacker obtains the data and can authenticate at will, while the customer may not be aware of this loss) but, unlike a password, it is impractical to change the original biometric. As the biometric is personal information, the loss of even a subset may breach the customer’s privacy.

5.Verifiers need to store the biometric templates andmust use the originaltemplate to enable authentication. Therefore the biometric templates cannot be stored using a hash function. The templates can be stored encrypted, as then the record can be recovered for authentication. The storage and control

�9

of biometric templates by those other than the customer raises concerns about privacy and function creep. Again, any attacks against biometrics are more severe than attacks against other authentication keys, because the loss of even part of someone’s biometric data breaches their privacy and it is not practical to change a person’s biometric.

6. A biometric stays largely the same over time. Indeed it is impractical to change them. For passwords and cryptographic keys, it is common security practice to change them within set timeframes in order to limit their vulnerability to discovery. Discovery with biometrics is quite different from secrets like passwords or cryptographic keys. However, the strength of cryptographic protections used to exchange biometric recordings needs to take into account the fact that they are (subsets of) personal information that is largely static.

Attack mitigated

Biometrics do counter keystroke logging, password discovery and shoulder-surfingattacks.Bythemselves,biometricsdonotmitigateanyoftheotherattackslisted in Table � and so additional protections need to be in place. For example, it is important to protect the communication channel.

Attacks not mitigated

As with passwords, the result of a successful attack is generally severe: the attacker obtains a copy of the customer’s biometric, a biometric reading, or the biometric template. Any may be used to fraudulently authenticate, potentially without the customer being alerted.

An additional problem is that the biometric cannot be replaced in the same way that other authentication keys can. Biometrics share many of the problems of personal information discussed following Table �. Biometric information is:

• restricted in scope• usually static (original cannot be changed)• degraded for authentication purposes as more organisations collect it• not secret and therefore vulnerable to being copied.

Summary

Biometrics have traditionally been used for local access control (for example, the photographs in passports). Their use is well established in such situations and the issues are understood. They are not well suited to remote authentication and need to be used in conjunction with other protections to ensure biometric data is notcaptured.Thiswouldincludecryptographicauthenticationoftheverifier(to

�0

avoid phishing of the biometric), requiring the customer to have at least a software token. This in part supersedes the use of a biometric-based authentication system for remote authentication.

Even when communication channel protections are used, biometrics are still susceptible to attacks that copy the biometric. Such attacks are likely to become more popular if biometrics are more widely used. Because biometrics are personal data, they have many of the problems relating to authentication methods that rely on personal information.

Privacy is an issue with regard to the storage, use and transfer of biometric data. The Biometrics Institute in Australia has a draft Privacy Code [��] that is currentlybeingreviewedbythe(Australian)OfficeofthePrivacyCommissionerpriortofinalpublication.Thedrafthasalreadybeenissuedforpubliccomment.The Department of Internal Affairs is developing a similar document for New Zealand government agencies. This document is intended for release by late �006. Further references and information for biometrics can be found in [�4].

RemarksIn general, authentication keys cannot be cleanly delineated into the factor categories. For example:

• Passwords can be used in the standard way, stored in a protected software module on a computer (usually protected using a master password), or stored on a hardware device. In the later two cases, the password is no longer something the customer knows, but something they have.

• A one-time password can be generated by a customer using a known base secret. In this case, the authentication key is something the customer knows rather than has.

For simplicity, the above section has not considered these and other variants.

References relating protections for hardware tokens, software tokens and one-time password devices are included separately in Appendix A.

��

Multi-factor Authentication Solution Selection Issues There are many issues to consider once a decision is made to use multi-factor authentication. The authentication key must also comply with the NZ e-GIF authentication standards [�], but many solutions may be available that satisfy these requirements.

The selection of the actual authentication key also needs to be based on a risk assessment for the particular service and also the business requirements. Agencies should use the Australian and New Zealand risk management standard AS/NZ 4�60:�004 [8] along with the associated handbooks AS/NZS HB 4�6:�004 [9] andSAA/SNZHB231:2004[10].Aconsiderationofprivacyriskscanbenefitfrom a privacy impact assessment. In this case agencies should refer to the Privacy Impact Assessment Handbook [�5]. For an example of business drivers, see the section on trends, which discusses the Land Information New Zealand Landonline service.

Others issues to consider include those listed in Table �. Further information can be found in [�5,�6,�8, �0, ��].

Table 3 – Solution selection issues

Issue Points to considerCustomer education

• Do customers have the necessary skills?• Are training resources available?• Ongoing education and awareness programmes must

be in place.Customer resources

• Do customers have the necessary basic hardware and software?

• Will extra special software need to be installed on customers’ computers or does the system rely on the customers having a special hardware?

• Will the system need to support multiple authentication keys to cover all customers?

• Is it assumed that customers’ computing environments may be hostile, or that common computer protections will be in place

Other (customer-related)

• How difficult will it be to achieve customer acceptance?

• What are the options for promoting acceptance?• Is portability a requirement?

��

Issue Points to considerStaff resources • What are the staffing requirements for the

development and ongoing operation of the system?• Will staff need additional training?

Systems operation • Does the system need to integrate with existing systems?

• What would migration of the existing system involve?• What reliability metrics need to be met?• Can the system scale if necessary?• Is interoperability with other systems a requirement?

If so, what is required?• What mix of proprietary and non-proprietary

technology will be used?• Systems issues are often complex but priorities

should relate to the vision an organisation has for its system.

System costs • What are the costs to deploy and run the system? This should include the development and ongoing operational cost. Costs will also be incurred to comply with Security in the Government Sector [4] and other acts, regulations and standards.

Business operation • Can the functions of the authentication key be leveraged for the business processes? This may be a driver for selecting one authentication key above others (an example is the Landonline system discussed below).

Deployment timeframes

• Are there timeframe restrictions for deploying the system? New solutions can take longer to deploy.

��

Government Use of Multi-factor AuthenticationGlobally, governments are moving towards offering their services online. Some governments are already employing multi-factor authentication methods to support their online services. Others are aiming to do so in the near future. The following examples are not intended to be comprehensive, but illustrate that up-take of multi-factor authentication in the government sector is occurring. General information has been sourced from [�6] and [��]. The New Zealand Government Logon Service is discussed in the next section.

• Austrian Government – Austria uses the “Citizen Card”, which is any device (smartcard, mobile phone, USB token, etc.) that is capable of creating secure digital signatures and can provide secure storage of personal data. Some functions and data are PIN protected against unauthorised use and/or access. The Austrian system is more technology-neutral than other initiatives: it relies on common functionality rather than a common form factor.

• Danish Government – The Danish Government is currently in the process of issuing free software tokens (used in conjunction with passwords) to all citizens to promote the uptake of their online services. These are viewed as being secure enough at this stage for most public sector and private sector transactions. There are currently no plans to introduce hardware tokens.

• Estonian Government – The government of Estonia began distributing ID cards (personalised smartcards) to its citizens in January �00�. The cards contain the individual’s name, address details, demographic information, as wellastwoPINprotecteddigitalcertificatesandrelatedcryptographickeys.A special distinction of this initiative is that Estonians can use their ID cards for accessing government services online and e-commerce applications, with both authentication and digital signatures being supported (by the separate certificates).Theauthenticationcertificate contains the individual’s emailaddress. The ID cards are mandatory for citizens and permanent residents over the age of �5.

• Italian Government – The Italian Government system uses their National Services Card and Electronic ID card, both of which are smartcards, for citizen authentication with online government services. The Electronic ID card is a hybrid smartcard that also contains PIN protected personal data including the holder’s blood group and fingerprint scans. The plan is toreplace all paper ID documents with these cards.

• Korean Government – The Korean Government is planning to have banks support one-time password systems for Internet banking. The project is being led by the Ministry of Information and Communication. Use of the one-time password system will not be mandatory but will allow citizens

�4

higher transactions amounts than the current one-time password system, which is based on cards that only store �0-�5 passwords. It is not clear whether the cards are re-used or if the card is replaced after the passwords have been used [�8].

• Malaysian Government – Malaysian Government issues citizens over �� years of age with a MyKad or Government Multipurpose Card [�9]. This is a tamper-resistant smartcard that performs public key cryptographic operations (including those relating to online authentication), supported by on-carddigitalcertificatesandagovernmentPublicKeyInfrastructure.TheMyKad is used for immigration at Malaysian borders, as a driving licence, to access government services online, for making online purchases, as an e-purse, and as an ATM card with participating banks.

• United Kingdom (UK) Government – The UK Government uses a centralised registration and authentication system called “The Government Gateway” to support secure authenticated e-government transactions over the Internet. Authentication of customers (individuals, organisations, or agents) is based on either a password or digital signatures (software tokens with password protection), depending on the type of transaction. There are plans to have the UK e-ID card support a digital signature function in the future. Refer to [�0] which discusses the UK and also the Dutch systems.

So governments are moving to provide two-factor authentication, which supports the provision of their services online. Sometimes this is bundled with other functions. This is the often the case with smartcard-based solutions – the smartcardisalsousedasanidentificationcard,traveldocumentande-commercecard. Providing support for a number of functions has motivated the uptake of online service by citizens in these countries.

Other nations have not reported such strong uptake but in some cases are limited in what they can offer by concerns about privacy. Where privacy is not an issue, the main barrier to uptake seems to be cost, usability and functionality. Some countries are addressing this with subsidies for their citizens, or even providing free two-factor authentication keys.

Note that the examples given here are only intended to demonstrate that a number of governments are using a range of two-factor authentication keys for the provision of government services online. Their inclusion is not intended as an endorsement of their appropriateness for the New Zealand Government.

�5

The Government Logon ServiceThe Government Logon Service (GLS) is being developed as part of the New Zealand All-of-government Authentication Programme. The Programme will standardise online authentication for New Zealand government services. The GLS will provide a common logon service for people using government services over the Internet. The GLS will allow customers to logon to different agency services using the same authentication key, or with multiple keys, in a secure and private manner.

Different types of authentication keys will be used depending on the level of identity-related risk. The Evidence of Identity Standarddefinesfourserviceriskcategories: No or Negligible, Low, Moderate and High [��]. These relate to the potential for harm if an error is made in attributing identity. The minimum authentication keys required for each service risk category are given in Table 4 below.

Table 4 - Minimum authentication keys required for service risk categories

Service risk category

Minimum authentication key requirements

Nil or negligible No requirement. Agencies are able to select their own authentication solution. If a password is used, this should be different from the password required for services in the Low service risk category.

Low Requires a one-factor authentication key in the form of a password conforming to the Password Standard [32].

Moderate Requires a two-factor authentication key that is at least one of the following:• a one-time password system combined with a

password• a one-time password device requiring per-session

local activation (with a password or biometric*)• a software token requiring per-session local

activation (with a password or biometric*).High Requires a two-factor authentication key that is at least

a hardware token requiring per-session local activation (with a password or biometric*).

* Currently, authentication solutions that incorporate the exchange of biometric data between a customerandverifierhavebeenexcluded.Reviewofbiometricauthenticationiscontinuingandtheirfuture use will be considered.

�6

The GLS will support authentication keys for the Low, Moderate and High service risk categories. The GLS currently supports password authentication, and support for a two-factor key is being developed. The advantages are that the customer will be able to use a single password, single software token, etc., to use online services with agencies that use the GLS. The GLS provides service customers with greater convenience in logon management since the GLS username and password (or other authentication key) can be re-used by the customer across different agencies. The design of the GLS protects the privacy of customers by not collecting any identity-related customer information.

TheIdentityVerificationService(IVS)isalsobeingdevelopedbytheProgramme.The IVS will allow service customers to establish their identity details, using the Evidence of Identity Standard, and to record them in the form of an electronic IdentityVerificationCredential(IVC).TheycanreleasetheIVCtoagenciestoconfirmtheiridentitywhentransactingelectronicallywiththegovernment.TheIVS is currently in the design phase. Figure � depicts the various communications. More information on the GLS can be found in [��].

Figure 3 - The GLS and IVS

Agencies

Service users

IVS

GLS

Internet

��

Trends The Internet is a very convenient channel for exchanging information and conducting business. It is also a very convenient place for criminal activities. Internet-based criminal activity is certain to increase. Government law enforcement agencies and Non-Government Organisations involved in incidence response have noted that organized crime is harnessing the potential of the Internet for illegal activities including scams, fraud, ID theft and extortion [��, �4]. These reports indicate that the nature of hacking itself has changed from being a harmless game to a business.

The losses from online fraud are currently smaller than off-line fraud, but the occurrence of online fraud is increasing at a rapid rate. Therefore, thought must be given to expand existing countermeasures and migration plans made for current systems. Currently, phishing and key logger attacks are popular for obtaining passwords and have been used in New Zealand [�5-�8]. Organisations whose business requires improved security to counter these increased threats are largely either at the stage of replacing passwords with some form of two-factor authentication or are planning to do so in the near future.

In New Zealand, ASB Bank and the associated Bank Direct launched their Netcode system at the end of �004. The Netcode system is based on a password and a one-time password that expires after a few minutes (an eight-digit code). The one-time password is sent to the customer’s cellphone in an SMS message. The Netcode system has been analysed by Thompson [�9]. ASB Bank, Bankdirect, HSBC and Rabobank also offer one-time password devices to support two-factor authentication of online banking customers [�8, 40]. In the USA, banking regulators will require banks to strengthen their online banking security by year-end �006, including two-factor authentication for high-value transactions or transfers of monies to secondary parties [�9]. This is also likely to happen in the near future in the UK [4�].

Land Information New Zealand (LINZ) uses two-factor authentication with its Landonline service [4�]. Landonline customers obtain a unique personal digital certificate andkeypair froman authorisedCertificateAuthority.This is usedwith software on their computer to perform the following functions:

• authentication to the Landonline system, which also requires a password• securing the communication channel with the Landonline system • digitally signing documents – for example, a solicitor can digitally sign the

necessary papers required for the transfer of land titles.

�8

Use of the digital certificate for signing is protected by a passphrase (thisis a type of password and is distinct from the password used to authenticate to theLandonline system).Thefirst two functionsaboveareexamplesof theauthentication key functions discussed in this Guidance whereas the third is an extra service supported by this technology, albeit one that is critical to the Landonline service.

�9

GlossaryTerm DefinitionActivation data Normally a password or biometric that is used

to authenticate to a hardware or software token or a hardware device before they may be used. Software tokens (in particular any related cryptographic keys or secrets) are normally protected under a key generated using the activation data.

Application Programming Interface (API)

Generic code sets used for implementing higher-level software applications.

Authentication Process of establishing, to the required level of confidence, the identity of one or more parties to a transaction. Consists of identity management (establishing who you are) and logon management (confirming who you are). In particular, for this Standard authentication is used in the commonly understood sense of a customer logging onto a service with their username and authentication key. This is consistent with the logon management aspect of the general authentication definition above.

Authentication key Method used by an individual to authenticate his or her identity over the Internet. Examples of authentication keys include passwords, one-time passwords, software tokens, hardware tokens, and biometrics. Authentication keys are also referred to as keys.

Automatic Teller Machine (ATM)

These machines accept ATM cards. ATM cards are moving from magnetic strip cards to smartcards, commonly called chipcards.

40

Term DefinitionChallenge/response An authentication protocol where the verifier sends

the customer a challenge (usually a random value or a nonce) that the customer combines with a shared secret (often by hashing the challenge and secret together) to generate a response that is sent to the verifier. The verifier knows the shared secret and can independently compute the response and compare it with the response generated by the customer. If the two are the same, the customer is considered to have successfully authenticated. When the shared secret is a cryptographic key, such protocols are generally secure against eavesdroppers. When the shared secret is a password, an eavesdropper does not directly intercept the password itself, but may be able to find the password with an off-line password guessing attack.

Cryptographic hash A function that maps a bit string of arbitrary length to a fixed length pseudo-random bit string. Approved hash functions satisfy the following properties: 1. (One-way) It is computationally infeasible to find any input that maps to any pre-specified output, and 2. (Collision resistant) It is computationally infeasible to find any two distinct inputs that map to the same output.

Cryptographic keys Protected values (in terms of their confidentiality and integrity) that are used in cryptographic operations.

Cryptographic operations

Special algorithms and protocols that may be used in the authentication process.

Form factor Relates to the physical dimensions and technical properties (such as the communications interface) of a hardware device.

Government Logon Service (GLS)

An all-of-government shared service that provides ongoing re-confirmation of online identity to participating agencies to the desired level of confidence.

Identity (ID) May be simply an identifier for an authentication key.

4�

Term DefinitionIdentity Verification Credential (IVC)

A unique electronic record maintained by the IVS of a person’s verified identity data.

Identity Verification Service (IVS)

An all-of-government shared service that provides individuals with the option to verify their identity authoritatively, online, and in real-time with participating agencies to a passport-level of confidence.

Mutual authentication Where both entities authenticate to each other (the authentications are normally based on the same or closely similar methods).

Nonce A value used in security protocols that is never repeated with the same key. For example, challenges used in challenge-response authentication protocols generally must not be repeated until authentication keys are changed, or there is a possibility of a replay attack. Using a nonce as a challenge is a different requirement from a random challenge, because a nonce is not necessarily unpredictable.

One-way function A function for which it is computationally infeasible to find any input that maps to any pre-specified output.

Online service Service that an agency offers through an interactive online delivery channel.

Personal Identification Number (PIN)

A password made for numeric characters only. Commonly four digits are used, as with ATM cards.

Public keys, private keys, asymmetric key pairs and public key cryptosystems

Public keys and private keys occur as pairs called asymmetric key pairs. The public key is (usually) the public part and the private key is the secret part of an asymmetric key pair. Public key cryptosystems can be used to encrypt, digitally sign or protect the integrity of data.

Public Key Infrastructure Covers the management, architecture, business processes, technical procedures and protocols relating to the well-organized use of public key cryptosystems (mostly concerning the public keys of asymmetric key pairs).

4�

Term DefinitionSmartcard A credit card like form factor with an Integrated

Circuit chip. Smartcards may be just memory cards but this Guidance considers smartcards that contain specialised cryptographic processors. Smartcards come in both contact and contactless forms. The contactless cards contain a small antenna for communicating with the reader.

Service risk category Each service risk category is defined based on the identity-related risk of a service and are detailed in the Evidence of Identity Standard.

Symmetric keys and symmetric cryptosystems

Symmetric keys are cryptographic keys that are used with symmetric cryptosystems to perform both the cryptographic operation and its inverse, for example to encrypt and decrypt. Symmetric cryptosystems can also provide data integrity: they can be used to create message authentication codes for data and to verify those codes.

Transport Layer Security (TLS)

Like the Secure Sockets Layer (SSL) protocol, which it supersedes, TLS provides a cryptographically protected channel for web browser exchanges. TLS is defined by the Internet Engineering Task Force. TLS is similar to the older SSL protocol and is effectively SSL version 3.1.

Uniform Resource Locator (URL)

A standardised address format for locating resources on the world wide web.

Universal Serial Bus (USB)

A multi-purpose computer software and/or hardware interface for interfacing with communication, storage, and peripheral devices.

Username Construction of alphanumeric characters that is used to identify a customer within the authentication system (the username is used to identify the customer, or rather their authentication key, to the verifier as part of the authentication process).

4�

Referenced documents[�] State Services Commission. �006. Authentication key strengths standard. Version �.0. www.e.govt.nz[�] State Services Commission. �006. New Zealand e-government interoperability framework (NZ e-GIF). Version �.0. www.e.govt.nz[�] Department of the Prime Minister and Cabinet. �00�. Security in the government sector. www.security.govt.nz [4] Government Communications Security Bureau. October �005. New Zealand security of information technology manual – NZSIT 400. Version �.0. www.gcsb.govt.nz[5] State Services Commission. �006. Guide to authentication standards for online services. Version �.0. www.e.govt.nz [6] State Services Commission. �005. Development goals for the state services. www.e.govt.nz[�] Privacy Act 1993. www.privacy.org.nz [8] AS/NZS 4�60:�004. Risk management (Australian/ New Zealand Standard). www.standards.co.nz[9] SAA/SNZ HB 4�6:�004. Risk management guidelines – Companion to AS/NZS 4360:2004 (Australian/New Zealand handbook). www.standards.co.nz[�0] SAA/SNZ HB ���:�004. Information security risk management guidelines (Australian/New Zealand handbook). www.standards.co.nz [��] AS/SNZ ISO/IEC ���99:�006. Information technology – security techniques – code of practice for information security management. www.standards.co.nz[��] AS/SNZ ISO/IEC ��00�:�006. Information technology – security techniques – information security management systems – requirements. www.standards.co.nz [��] State Services Commission. �4th November �004. Trust and security on the internet – keeping the Internet safe for e-government in New Zealand. www.e.govt.nz[�4] Emigh, Aaron. �rd October �005. Online identity theft: Phishing technology, chokepoints and countermeasures. www.antiphishing.org (Accessed ��th May �006)[�5] Allan, Ant. ��th May �00�. Authentication tokens: Overview. Gartner Research Report DPRO-�049��. www.gartner.com[�6] APEC Telecommunications and Information Working Group. �00�. Electronic authentication: Issues relating to its selection and use. www.apec.org/apec

44

[��] Burr, William. Dodson, Donna D. Polk, W. Timothy. April �006. NIST special publication NIST 800-63 – electronic authentication guideline. Version �.0.�. www.csrc.nist.gov[�8] Henderson, Marie. February �999. Smart cards and PC cards. Defence Science and Technology Organisation Technical Report DSTO-TR-0��4. www.dsto.defence.gov.au[�9] Federal Financial Institutions Examination Council. October ��th �005. FFIEC guidance – authentication in an internet banking environment (FIL-�0�-�005). www.fdic.gov[�0] Grand, Joe. �9th September �00�. Authentication tokens: Balancing the security risks with business requirements. www.atstake.com (Accessed ��th May �006)[��] Smith, Richard. �00�. Authentication: From passwords to public keys. Addison-Wesley.[��] Matsumoto, Tsutomu. �nd-�rd October �004. Gummy finger and paper iris: an update. Presentation at the �004 Workshop on Information Security Research, Fukuoka Japan. www-kairo.csce.kyushu-u.ac.jp/WISR�004/presentation��.pdf (Accessed ��th May �006).[��] Biometrics Institute. �0th November �005. Biometrics institute privacy code. www.biometricsinstitute.org (Accessed ��th May �006).[�4] Roberts, Chris. Biometrics. November �005. Unpublished research. (Personal communication – received �6th November �005.) [25] OfficeofthePrivacyCommissioner.Privacy impact assessment handbook. www.privacy.org.nz[�6] IDABC – eGovernment Observatory. eGovernment factsheets. europa.eu.int/idabc/ (Accessed ��th May �006.)[��] CardTechnology. �st June �005. Going global with national ID. www.cardtechnology.com (Accessed ��th May �006.)[�8] Downing, Jim. �0th September �005. One-time password (OTP). www.smartmobs.com (Accessed ��th May �006.)[�9] Government Technology International. �9th April �00�. MyKad: The Malaysian Government multipurpose card. www.centerdigitalgov.com/international/ (Accessed ��th May �006.)[�0] Lips, M. Taylor, J. Organ, J. 9th September �005. Electronic government: Towards new forms of authentication, citizenship and governance. www.oii.ox.ac.uk/research/cybersafety/ (Accessed ��th May �006.)[��] Department of Internal Affairs. �006. Evidence of identity standard. Version �.0. www.dia.govt.nz[��] State Services Commission. �006. Password standard. Version �.0.

45

www.e.govt.nz[��] State Services Commission. �005. Authentication for e-government: Government Logon Service design overview. www.e.govt.nz[�4] AusCERT, Australian Federal Police, Australian High Tech Crime Centre, New South Wales Police, Northern Territory Police, Queensland Police, South Australia Police, Tasmania Police, Victoria Police, Western Australia Police. �006. 2006 Australian computer crime and security survey. www.auscert.org.au/crimesurvey[�5] Ilett, Dan. 6th September �005. Fighting back against the phishers. software.silicon.com (Accessed ��th May �006.)[�6] Greenwood, Darren. �st April �005. Phishing for security. www.misweb.com (Accessed ��th May �006.)[��] New Zealand Herald. �th March �005. Internet banking under scrutiny after hacker accesses accounts. www.nzherald.co.nz (Accessed ��th May �006.)[�8] Sonti, Chalpat. �6th May �006. Robbed by the spy in her PC. www.stuff.co.nz (Accessed ��th May �006.)[�9] Thompson, Kerry. �8th September �004. A security review of the ASB bank netcode authentication system. www.crypt.gen.nz (Accessed ��th May �006.)[40] Schwarz, Reuben. ��st October �005. ASB device ups online security. www.stuff.co.nz (Accessed ��th May �006.)[4�] Robertson, Struan. �9th October �005. UK law will demand better authentication for online banking. www.out-law.com (Accessed ��th May �006.)[4�] Land Information New Zealand. Landonline service. www.landonline.govt.nz

Latest revisions

This Guidance is to be reviewed from time to time, so that it keeps up to date with changes in the sector. Users should ensure they access the latest revisions of this Guidance. These can be found at www.e.govt.nz. Users should also access the latest revisions of the documents included in the list of referenced documents.Review of Guidance

Suggestions for improvement of this Guidance are welcomed. They should be sent to the Manager, e-GIF Operations, State Services Commission, PO Box ��9, Wellington. Alternatively, suggestions can be sent by email to e-gif@ssc.govt.nz

46

Appendix A. Technical Protection ReferencesThe following references may be useful in determining and evaluating the protection and/or tamper resistance features of hardware tokens, software tokens and one-time password devices.

Ant Allan, Authentication Tokens: Overview, Gartner Research. DPRO-104977 (www.gartner.com)

Contains tables of:

• relevant authentication algorithms and protocols from the ISO/IEC standards, ANSI standards, FIPS publications, IETF standards and ITU-T standards

• hardware token standards: ISO/IEC Identification Cards standards, RSALab’sPKCSCryptographicTokensandPC/SCspecifications

• vendors’ authentication tokens.

ISO/IEC JTC 1/SC 27 and TC 68/SC 2*

ISO/IEC �5408 series. Information Technology - Security Techniques - Evaluation Criteria for IT Security:

• Part �: Introduction and General Model (ISO/IEC �5408-�:�005)• Part �: Security and Functional Requirements (ISO/IEC �5408-�:�005)• Part �: Security Assurance Requirements (ISO/IEC �5408-�:�005).ISO/IEC

�544� series.

Information Technology – Security Techniques – A Framework for IT Security Assurance:

• Part �: Overview and Framework (ISO/IEC TR �544�-�:�005)• Part �: Assurance Methods (ISO/IEC TR �544�-�:�005)• Part �: WD TR �544�-�.

ISO/IEC �8045:�005. Information technology - Security Techniques - Methodology for IT Security Evaluation.

ISO/IEC FDIS �9�90. Information Technology - Security Techniques - Security Requirements for Cryptographic Modules. (This standard has been derived from NIST Federal Information Processing Standard PUB �40-�)

ISO/IEC ��8��:�00�. Information Technology - Systems Security Engineering - Capability Maturity Model.

ISO/IEC NP �4�45. Information Technology - Biometric Template Protection.

ISO/IEC NP �4�59. Information Technology - Security Techniques – Requirements for Cryptographic Modules.

4�

ISO/IEC NP �4�6�. Biometric Authentication Context.

ISO ��49� series. Banking - Secure Cryptographic Devices (retail):

• Part �: Concepts, Requirements and Evaluation Methods (ISO ��49�-�:�998 / ISO/CD ��49�-�)

• Part �: Security Compliance Checklists for Devices used in Financial Transactions (ISO ��49�-�:�005).

ISO �909� series. Financial Services - Biometrics:·

• Part �: Security Framework (ISO/DIS �909�-�)

• Part �: Cryptographic Techniques (ISO/CD �909�-�).

*The full list of ISO/IEC standards for JTC �/SC �� and TC 68/SC � should be reviewed for new publications.

Common Criteria Protection Profiles.

Common Criteria (www.commoncriteriaportal.org)

• ProtectionProfile–SecureSignature–CreationDeviceType1,Type2,andType �. April �00�.

• Public Key Infrastructure and Key Management Infrastructure Token (Medium Robustness) PP. March �00�.

• Smart Card IC Platform PP. July �00�.

• Smart Card IC with Multi-Application Secure Platform. January �00�.

• Smart Card Integrated Circuit with Embedded Software. July �999.

• SmartCardUserGroup–SmartCardProtectionProfile.October2001.

• U.S. Government Biometric Verification Mode Protection Profile forMedium Robustness Environments. November �00�.

Communications Electronics Security Group (www.cesg.gov.uk)

• BiometricDeviceProtectionProfile(BDPP).UKGovernmentBiometricsWorking Group. Draft Issue 0.8�. 5 September �00�.

• Best Practices in Testing and Reporting Performance of Biometric Devices, Version �.0, �� January �000.

48

Other

Security Requirements for Cryptographic Modules. Federal Information Processing Standards PUB �40-�. �5 May �00�. (Note ISO/IEC �9�90:�006 is derived from this standard)

Information Technology Security Evaluation Criteria (ITSEC), Harmonized Criteria of France – Germany – the Netherlands – the United Kingdom, Version �.�, January �99�.

Department of Defense, Department of Defense Trusted Computer Eyetem Evaluation Criteria, DOD 5�00.�8-STD, December �985.

Guidance on Multi-factor Authentication

Gui

danc

e on

Mul

ti-fa

ctor

Aut

hent

icat

ion

June

200

6