doc8752
Application Note
Using the Atmel ATSHA204 for Secure Password Operations
Features
• Securely store passwords
• Check password without revealing expected value
• Map password to high entropy key
1.
Introduction
Passwords are used in many digital systems that contain a user interface. They
provide a convenient and well-understood mechanism for limiting access, enabling
features, and many other purposes. In a typical digital system without any sort of
secure hardware device, however, there can be many weaknesses in the overall
password process.
There are a several classes of security concerns, but generally they fall into two
categories:
1.
Is the correct password stored where an attacker can get access to it in any
way? Does the password appear in the clear on any internal or external bus or
connection that an attacker can watch? Can this information be retrieved
remotely, or does the attacker have to have physical access to the system?
2.
If getting to the password itself cannot be accessed, can the attacker mount an
offline attack to analyze the available information and find the password? One
kind of such an analysis is an exhaustive dictionary attack.
Secure hardware devices can provide mechanisms to hide the clear value of the
password, prevent offline exhaustive attacks, and greatly increase the difficulty of
®
local, physical attacks. The Atmel ATSHA204 provides such a capability in a very
small package and at a low cost. It is easy to integrate into any digital system.
Here are five typical use models for passwords, possible security concerns, and
ways in which the ATSHA204 addresses these concerns.
8752A−CRYPTO−4/11
•
Password validity
Was the entered password correct? If so, the system might enable various features or actions. In some systems,
the expected password might be stored in a serial EEPROM or flash memory that an attacker could easily read.
The Atmel ATSHA204 stores the correct password in internal, high-security, nonvolatile memory and does the
comparison internally. It returns a simple yes/no answer to the system, so the attacker never has any access to
the correct password.
•
Secure password transmission
In many systems, the user-entered password may have to pass over a wired or wireless connection to get to
the system. An attacker can watch this communication and read the value that a user has entered, allowing the
attacker to fraudulently send it again later.
The Atmel ATSHA204 allows the entry device to mix (using SHA-256) the entered value with a random
number before transmitting it. The Atmel ATSHA204 performs the same mixing function to determine validity. In
this way, the snooper can’t tell what the actual password is or resend the same message later and get a
successful response.
•
Password as encryption key
If the local system contains bulk storage such as flash memory or needs to process encrypted communications
packets, then it may not be sufficient to know that a valid user is present. If the password is used for the
encryption/decryption key then the local system needs the actual password value. This value would then be
susceptible to malware or debuggers, either of which might be watching internal busses.
The Atmel ATSHA204 permits the system designer to securely combine the password with a visible number.
The result is used as an ephemeral session key for communications or as a file-specific decryption key for data.
•
Password mapped to secure encryption key
Since the entropy (complexity or randomness) of most people’s passwords is limited, in the above cases it is
usually possible for an attacker watching the bus to “try all possible combinations” and determine what the
password was.
To combat this, the Atmel ATSHA204 provides a way to map a particular password into a high-entropy key that
is then used for the encryption/decryption purpose. Exhaustive attacks on this key are essentially impossible.
•
Password recovery
One well known problem with passwords is that people often forget them. Some sort of recovery mechanism is
usually desirable in order to permit continued use of the system or data. If this mechanism provides access to
either the old or new password value, an attack has gained hit pay dirt a distinct advantage.
The Atmel ATSHA204 provides several methods of updating or recovering a password using completely
encrypted data to maintain the same level of security as with general usage.
It’s important to note that no security system is perfect and those that include a user password are always susceptible
to social engineering and other possible attack vectors that are not addressed here.
2.
Password Security Issues
There are a number of well-known limitations to the password entropy, including:
•
Sometimes the password is really only a four digit PIN. If there is any way to electronically try values, then the
attack is easy because there are so few possibilities.
•
Absent an enforced policy to the contrary, many people will use a single name or a word in a dictionary as their
password
In addition, multiple protocol and/or policy concerns exist including the following:
•
It is common to use the same password for many systems, and so the security of the password is only as strong
as the security of the weakest system
•
If the entered password is transmitted over an accessible bus, an attacker may be able to siphon off the value
without the user knowing that the breach has occurred
Using the Atmel ATSHA204 for Secure Password Operations Application Note
8752A−CRYPTO−4/11
2
The most serious problems with passwords occur when an attacker can remotely determine the password without the
user knowing that the password is at risk, even without physical access to the secured system. Offline attacks such as
these can employ a network of high-speed computers for the analysis, and are sometimes known as dictionary attacks
because the computer might try all the words in a dictionary. In the example that a password is directly used as an
AES key to encrypt a file, the attacker can copy the encrypted file to many computers and have each computer search
a portion of the universe of password possibilities for proper decryption at a very rapid rate.
Even “strong” password policies do not provide much defense against an offline exhaustive attack. Assume a policy
that states that a password must be more than eight characters long, and include a number and at least one nonalphanumeric character. An offline attacker might think about this as follows:
•
The attacker could guess that a password contains one or two words or names. According to Wikipedia, around
6,000 words comprise 90% of written English text and according to the 1990 US Census, 4,250 female names
and 1,208 male names cover 90% of the population. This yields 11,458 × 11,458, or 131,000,000 possibilities
to check. (These statistics will vary by country and language, but not sufficiently to change the outcome of this
estimate.)
•
Typically, the numerical portion would be small to be easy to remember and it probably does not occur in the
middle of a word. The attacker might assume that it has a maximum value of 31, as days of the month are
commonly remembered. For a two word password, this adds a factor of 32 × 3, or 96. (Often vowels or similarlooking letters are substituted for numbers; o=0, e=3, i=1, p=9, @=a, etc. This is also well known by dictionary
attackers)
•
There are only 30 non-alphanumeric characters on a typical Western keyboard, and these might occur only at
the beginning or end of the password. This adds another factor of 30 × 2, or 60.
12
The total number of possibilities to check would then be around 8 × 10 . If the attacker has 20 computers, each
with a quad-core processor, 80 possibilities at a time can be tried. In 2011, 3GHz processors are common. If it
takes 30,000 instructions to try one possibility, then each processor can try 100,000 possible passwords per
second. In this hypothetical situation, the attacker can check all the password combinations within 27 hours.
By contrast, using the most secure sequence described below in Section 3, with a single ATSHA204 (perhaps one
that was stolen) to check each password (i.e. an online exhaustive attack); it would take around 25,000 years to get
to the end of the list.
The best passwords are large completely random numbers. Depending on the situation and the expert you ask,
completely random numbers in the range of roughly 80-128 bits simply cannot be exhaustively attacked. Passwords
(or keys) stored in the ATSHA256 are 256 bits long, by comparison.
Most people can’t remember long strings of random characters, and so the reality is that passwords will never achieve
anywhere near the strength of a good random number. Because of this, the ability to translate a weak password into a
strong random number is a significant advantage, especially for flash drives, medical equipment, and other systems
that store data.
3.
Implementation Details
The implementation examples below are all expressed in terms of a user entering a “password” via some user
interface. Often the password would actually be a SHA-256 digest of a passphrase so that the system gets a uniform
length password regardless of the size of the item the user types. In cases where the ATSHA204 is in a physically
secure location, the password might simply be a four-digit PIN.
Please consult the full datasheet for the Atmel ATSHA204 at www.atmel.com for information on command details. In
addition, the Atmel web site includes various other application notes and source code libraries to facilitate
development of the system.
The following example sequences show how to enable some common requirements. There are, of course, many
combinations of the following sequences that can provide the best possible level of security.
3
Using the Atmel ATSHA204 for Secure Password Operations Application Note
8752A−CRYPTO−4/11
3.1.
Enabling Access to a Stand-alone System
Many digital systems need a way for a factory maintenance technician to enable certain features or display certain
data. For a personal medical monitoring device, either the doctor or the patient may want access to certain capabilities
or information to become available only upon entry of the correct password.
In these and other situations, it is helpful to be able to store the expected password in a secure device and permit that
device to do the password comparison internally. The ATSHA204 implements this capability easily. The basic
implementation is as follows:
1.
2.
3.
3.2.
The system sends the nonce command to the Atmel ATSHA204 to generate a random nonce. The random
number portion of this nonce is returned to the system.
The user interface accepts the password from the user, and the system hashes the password with the nonce
from step 1.
The Atmel ATSHA204 computes same digest using the internally stored password, compares it with the system
computation from step 2 using the CheckMac command, and returns True/False to the system.
Password Entry for Server Room Access
One straightforward use for a password is to enable access to a server room (or any other secured area) via a keypad
next to the door. However, it is not as simple as it seems to build such a remote keypad device:
1.
If the password is transmitted to the central controller in the clear, then a snooper can easily learn the password
value by tapping onto the bus or monitoring the wireless signal.
2.
If the password is hashed with a fixed masking key associated with the keypad, then the system is subject to a
replay attack.
3.
If the central controller sends down a random challenge, which is then hashed with the password at the keypad,
the system is subject an offline attack.
One excellent strategy is to combine the second and third options above, using the ATSHA204 to store the fixed key
and compute the hashing operations inside the chip. An added benefit of this configuration is that the ATSHA204 can
generate a high-quality random number at the keypad, providing additional protection against a spoofed central
controller. The same masking secret can be used in each keypad if the ATSHA204’s unique serial number is included
in the calculations.
The basic implementation is as follows:
1.
3.3.
The central controller generates a random challenge and sends it to the keypad
2.
The Atmel ATSHA204 generates a random number and sends it to the system
3.
4.
The ATSHA204 combines the random number from step 2 with the input challenge from the controller
The ATSHA204 combines the output of step 3 with the masking key stored in the ATSHA204’s EEPROM
5.
The keypad user interface accepts the password from the user. The user can optionally send a user ID in the
clear
6.
7.
The ATSHA204 combines the password with the output of step 4 and sends the result to the controller
The controller matches the result from step 6 with the expected value
Server Room Access with a Limited Number of Personnel
If the central control system requires only a limited number of passwords (perhaps less than 10-12), then the
ATSHA204 is also ideal as the central controller. On the controller side, the ATSHA204 can:
•
Securely store the masking key
•
Securely store all the passwords (up to the number of free slots in the ATSHA204), preventing one employee
from learning the passwords of another employee
•
Securely validate the response code from the keypad
Using the Atmel ATSHA204 for Secure Password Operations Application Note
8752A−CRYPTO−4/11
4
3.4.
Password as Encryption Key in Flash Drive
In a flash drive, a password might be used as the file encryption key. Since the same password protects every file on
the drive, the password value must be carefully protected. The problem is that in a simple implementation, the
password has to be passed in the clear to the flash drive, which then uses it as the file decryption key. This leaves it
susceptible to loss due to malware on the PC.
The ATSHA204 provides an excellent mechanism for implementing both the secure transfer of the password, and if
the password matches, a hash combination of the password with an encrypted file key blob to permit external
decryption of the file. The value of the password is never revealed on any bus within the flash drive, nor even inside
the memory of the processor on the flash drive.
The basic implementation is as follows:
1.
The computer sends the Nonce command to the ATSHA204 in the flash drive to generate a random nonce
2.
The random number portion of this nonce is returned to the computer. The password is entered by the user and
combined with the random number in software using the ATSHA256. The digest is then passed back to the
flash drive over the USB bus.
The ATSHA204 CheckMac command accepts the digest from step 2, internally calculates the expected value,
and returns a boolean on success
3.
3.5.
4.
In addition, the CheckMac command in step 3 should be run in copy mode, in which case, the password will be
copied to TempKey
5.
The individual file encryption key blob is retrieved from the flash memory and combined with the password
using the Mac command. The resulting digest is used as the AES decryption key for the file.
Password Mapped to Secure Encryption Key in Flash Drive
This is the most secure mechanism for encrypting or decrypting files on a flash drive, data in a personal medical
monitoring device, and related applications. It combines the advantages described in the previous section with two
additional features:
1.
Secondary obfuscation of the password when transmitted over the bus to prevent an offline attack on the bus
traffic which might reveal the password.
2.
A hardware ‘translation’ of the password into a completely random, 256-bit key. An attacker with access to the
encrypted files can no longer mount an offline attack on the file encryption keys.
The basic implementation is as follows:
5
1.
2.
The ATSHA204 generates a random number and sends it to the system
The system hashes this random number with a “masking secret” compiled into software
3.
System accepts password from UI, hashes it with digest from step 2, sends to the flash drive containing the
ATSHA204
4.
The ATSHA204, using the “masking secret” and password stored in two separate slots, checks for correctness
of the password.
5.
6.
If the digests match, the ATSHA204 copies the “encryption secret” to TempKey
The ATSHA204 combines the value in TempKey with the key blob stored with the encrypted file, generating an
AES key specific to that file.
7.
The processor in the flash drive or main system decrypts (encrypts) the file
Using the Atmel ATSHA204 for Secure Password Operations Application Note
8752A−CRYPTO−4/11
3.6.
Password Mapping for Websites
Generally, passwords entered into a website are transmitted to the server using some sort of secure protocol (usually
SSL/TLS). Such protocols are very effective in ensuring that access to the packets as they pass through the internet
does not yield the value of the password to an attacker.
Nonetheless, there are a few cases where having the ATSHA204 in a USB dongle attached to a PC can offer improved
security, convenience, and/or flexibility.
3.7.
•
To implement a dual-factor (what you know – password, and what you have – the dongle) authentication
scheme, the USB dongle could act independently of the password mechanism
•
Especially where local operations are enabled, mapping a low entropy user password to a high entropy
cryptographic key can reduce exposure to offline exhaustive attacks on the data. This key could also be sent to
the website in place of the password to improve the overall security.
•
In some website architectures, it may be beneficial to do the opposite, map all individual user passwords to a
single secret key that enables access to some capability.
Note: In this case, there is no need to store multiple passwords on the server. If the server has a
complementary ATSHA204 chip attached in some way, there is no need to store any secret on the
server.
Password Recovery
The usual method of recovering a password is for an administrator to have permissions to write a new password if the
old one is forgotten. The ATSHA204 supports this through the encrypted write capability, storing the administrator
secret in a slot separate from the password.
Note:
This can take a hierarchical form, with some super-admin recovering the administrator secret and so on
An alternate method of recovery is to permit the administrator to read the current value of the secret, again storing
the administrator secret in a slot separate from the password.
It is often useful to be able to update the password if knowledge of the current password can be proven (password
expiry). The ATSHA204 also permits this through the encrypted write capability, where the encryption and
authentication key for the write is the existing value of the password.
The ATSHA204 does not permit two entities to control writes to a slot, and so it is not possible for a user to write a
new password either with knowledge of the current password, or with knowledge of an administrator secret.
However, the part can be configured to permit password writes with knowledge of the current password at the same
time as allowing password reads with the knowledge of the administrator secret.
The basic method to implement this last configuration is as follows:
•
Configure the password slot to accept encrypted reads and encrypted writes
•
Set ReadKey to point to the slot containing the administrator key
•
Set WriteKey to point to the password slot itself
Using the Atmel ATSHA204 for Secure Password Operations Application Note
8752A−CRYPTO−4/11
6
4.
7
Revision History
Doc. rev.
Date
Comments
8752A
04/2011
Initial document release
Using the Atmel ATSHA204 for Secure Password Operations Application Note
8752A−CRYPTO−4/11
Atmel Corporation
Atmel Asia Limited
Atmel Munich GmbH
Atmel Japan
2325 Orchard Parkway
San Jose, CA 95131
USA
Tel: (+1)(408) 441-0311
Fax: (+1)(408) 487-2600
www.atmel.com
Unit 01-5 & 16, 19F
BEA Tower, Millennium City 5
418 Kwun Tong Road
Kwun Tong, Kowloon
HONG KONG
Tel: (+852) 2245-6100
Fax: (+852) 2722-1369
Business Campus
Parkring 4
D-85748 Garching b. Munich
GERMANY
Tel: (+49) 89-31970-0
Fax: (+49) 89-3194621
9F, Tonetsu Shinkawa Bldg.
1-24-8 Shinkawa
Chuo-ku, Tokyo 104-0033
JAPAN
Tel: (+81)(3) 3523-3551
Fax: (+81)(3) 3523-7581
© 2011 Atmel Corporation. All rights reserved. / Rev.: 8752A−CRYPTO−4/11
Atmel®, logo and combinations thereof, CryptoAuthentication™ and others are registered trademarks or trademarks of Atmel Corporation or its subsidiaries. Other terms and
product names may be trademarks of others.
Disclaimer: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Atmel
products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND CONDITIONS OF SALES LOCATED ON THE ATMEL WEBSITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY
RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT,
INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR
INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and
reserves the right to make changes to specifications and products descriptions at any time without notice. Atmel does not make any commitment to update the information contained herein. Unless specifically provided otherwise, Atmel products are not
suitable for, and shall not be used in, automotive applications. Atmel products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement