The following are comments on the recently released drafts of NISTIR 7981, "Mobile, PIV, and Authentication," and NIST Special Publication 800-157, "Guidelines for Derived Personal Identity Verification (PIV) Credentials," both dated March 2014. For further discussion, please do not hesitate to contact us by email or phone, as follows: - Francisco Corella, fcorella at pomcor.com, (619)770-6765. - Karen Lewison, kplewison at pomcor.com, (669)300-4510. EMAIL-RELATED CREDENTIALS SP 800-157 is ambiguous as to whether derived credentials include email-related credentials, i.e. digitial signature and key management private keys and associated certificates such as those present in a PIV card. Section 1.2 states that only the PIV Derived Authentication certificate is a Derived PIV Credential. But the informative Appendix A states that "a subscriber who has been issued a PIV Derived Authentication certificate for use with a mobile device may also have a need to use a digital signature and key management key with that mobile device." And the PIV Derived Application Data Model of normative Appendix B includes the digital signature private key and certificate, and both current and retired key management private keys and certificates. Email reading, and to some extent writing, has traditionally been the main business use of mobile devices. Therefore users with email accounts need email-related credentials on their mobile devices as much as an authentication credential. Email-related credentials should be called derived credentials, and guidance related to them should be normative rather than informative. Guidance on the current and retired key management keys should explain that they must be the same as those on a PIV card because they must be used to decrypt the same collection of email messages, including old email messages that have been saved encrypted, and should specify or at least suggest that they should be downloaded from an escrow server. The PIV Derived Application Data Model might allow for the storage of more than 20 retired key management keys and certificates, since the constraints that limit the number of retired keys and certificates in PIV cards may not exist in mobile devices. NISTIR 7981 argues that email-related credentials need lower assurance than authentication credentials (lines 407-411). In fact the opposite is true. Capturing a key-management key may allow an adversary to decrypt a large collection of emails captured in encrypted form over a long period of time. It is also more difficult to protect a key-management key than an authentication key: revoking the certificate associated with an authentication key terminates access to resources protected by the key, but revoking the certificate associated with a key management key does not prevent the adversary from using the key to decrypt previously captured emails. Thus an adversary who captures a key-management key encrypted under a key derived from a password has an unlimited amount of time to run an offline password-guessing attack in order to obtain the key-management key and decrypt previously captured emails. TEE TOKENS An important new trend in mobile security hardware calls for implementing a cryptographic module within a Trusted Execution Environment (TEE) or TrustZone provided by a secure OS running on the same processor as a normal OS. A hardware bus architecture ensures that a portion of the flash storage can only be accessed by the secure OS. Both OSes can access the touchscreen, but a security indicator lets the user know whether the screen is controlled by the secure OS and the user interface can be trusted. TEEs are available in ARM Cortex-A processors [1], with specifications being developed by GlobalPlatform [2]. Development of Trusted Applications (TAs) that will run in a TEE is supported by Trustonic [3] and Sierraware [4]. The GlobalPlatform TEE specifications include a Trusted User Interface API specification [5]. A cryptographic module running in a TEE could be called a TEE token. Although TEE tokens are a special case of embedded tokens, they deserve a special mention because of their pros and cons for the storage of derived credentials. The Trusted User Interface feature can be used to protect the token activation PIN or password from being phished by malware. On the other hand, since the secure OS runs on the same processor as the normal OS and uses a portion of the same flash storage, a TEE token typically provides no tamper resistance. LACK OF SECURITY OF SOFTWARE TOKENS Section 3.4.2 of SP 800-157 requires the Subscriber to authenticate to a software token with a password that meets the requirements of an LOA-2 memorized secret token as specified in Table 6 of SP 800-63, which are as follows: "The memorized secret may be a randomly generated PIN consisting of 6 or more digits, a user generated string consisting of 8 or more characters chosen from an alphabet of 90 or more characters, or a secret with equivalent entropy." In SP 800-63 those token requirements are coupled with the following verifier requirements: "The Verifier shall implement a throttling mechanism that effectively limits the number of failed authentication attempts an Attacker can make on the Subscriber's account to 100 or fewer in any 30-day period." The necessity of the coupling is emphasized in Section 8.2.3 of SP 800-63: "When using a token that produces low entropy token Authenticators, it is necessary to implement controls at the Verifier to protect against online guessing attacks. An explicit requirement for such tokens is given in Table 6: the Verifier shall effectively limit online Attackers to 100 failed attempts on a single account in any 30 day period." But in SP 800-157, whereas 3.4.1 requires a mechanism to block the use of a derived credential after a number of consecutive failed authentication attempts for hardware tokens at LoA-4, 3.4.2 requires no blocking for software tokens, contradicting the guideline of SP 800-63. Furthermore, NISTIR 7981, lines 289-291, states that a software token "stores the keys in flash memory on the mobile device protected by a PIN or password." Although this is not explicitly stated, it would be reasonable to assume that such a PIN or password is the password of Section 3.4.2 of SP 800-157, which is only required to have 20 bits of entropy; and although the method of protection is not specified, it would be reasonable to assume that the keys are to be encrypted under a data encryption key derived from the PIN or password and a salt, using a key derivation function. Even if the key derivation function is PBKDF2 [6] with a large number of iterations, such method of protection provides no security against an adversary who extracts the encrypted keys from the software token and carries out an offline brute-force attack agaisnt the PIN or password using a botnet. Botnets with tens-of-thousands of machines can be rented for a few dollars an hour or a few hundred dollars a day [7,8]. Botnets are typically used for DDOS attacks, but can easily be repurposed for PIN or password cracking attacks. There are however means of providing strong security for derived credentials stored in software tokens (as well as in TEE tokens). We believe it is important to include such means in the guidelines provided to Federal agencies by SP 800-157. METHOD FOR SECURING DERIVED CREDENTIALS IN SOFTWARE TOKENS While mere encryption under a key derived from a PIN or password is not sufficient for protecting derived credentials stored in a software token, an alternative protection method can provide effective security against an offline attack. NISTIR-7981 emphasizes the always-on, always-connected nature of mobile devices. One benefit of mobile devices being always connected is that it makes it possible to enlist the help of a secure back-end. Specifically, it makes it possible to use a random high-entropy key to encrypt the credentials stored in a software token, storing the high-entropy key in the secure back-end and retrieving it when the user activates the software token. The problem, of course, is how to retrieve the high-entropy key from the back-end. In order to retrieve the key securely, the mobile device must authenticate to the back-end, using a credential stored in the mobile device, which seems to bring us back to square one. However, there is a difference between this device-authentication credential and the credentials stored in the token: the device-authentication credential is only needed for the specific purpose of authenticating the device to the back-end and retrieving the high-entropy key. This makes it possible to use as device-authentication credential a credential regenerated on demand from the activation PIN or password and a protocredential stored in the device, in a way that deprives an attacker who captures the device of any information that would make it possible to test the guesses of the PIN or password that would be made in an offline guessing attack. The device-authentication credential can consist, for example, of a DSA key pair whose public key is registered with the back-end, coupled with a handle that refers to a device record where the back-end stores a hash of the registered public key. In that case the protocredential consists of the device record handle, the DSA domain parameters specified in Section 4.3 of the Digital Signature Standard (DSS) [9] and a random high-entropy salt. To regenerate the DSA key pair, a fast key derivation function such as HKDF [10] is used to compute an intermediate key-pair regeneration key (KPRK) from the activation PIN or password and the salt, then the DSA private and public keys are computed as specified in Appendix B.1.1 of the DSS, substituting the KPRK for the random string returned_bits. To authenticate to the back-end and retrieve the high-entropy key, the mobile device establishes a TLS connection to the back-end, over which it sends the device record handle, the DSA public key, and a signature computed with the DSA private key on a challenge derived from the TLS master secret. The DSA public and private keys are deleted after authentication, and the back-end keeps the public key confidential. An adversary who is able to capture the device and extract the protocredential has no means of testing guesses of the PIN or password other than regenerating the DSA key pair and attempting online authentication to the back-end, which locks the device record after a small number of consecutive failed authentication attempts that specify the handle of the record. More information can be found in [11]. A COMPENSATING CONTROL OMB memorandum M-07-16 [12] includes the following security requirement for remote access to federal information: "Allow remote access only with two-factor authentication where one of the factors is provided by a device separate from the computer gaining access." Appendix C of SP800-157 observes that this requirement is not met by derived credentials stored in tokens integrated into the mobile device, but anticipates that OMB will issue alternative guidance allowing compensating controls to make up for the use of integrated tokens. The OMB requirement is not met, in particular, by software tokens or TEE tokens. There is another requirement that is not met by software tokens or TEE tokens, viz. tamper resistance. HSPD-12 [13] requires tamper resistance for protection of federal credentials: '"Secure and reliable forms of identification" for purposes of this directive means identification that [...] (b) is strongly resistant to identity fraud, tampering, counterfeiting, and terrorist exploitation [...]' Encrypting derived credentials under a high-entropy key stored in a secure back-end can serve as a compensating control for both the lack of separation and the lack of tamper resistance of software tokens and TEE tokens, as long as the high-entropy key is retrieved securely as described above. Storing the high-entropy key used to encrypt the derived credentials away from the mobile device seems a suitable compensating control for not storing the derived credentials themselves away from the device. And encrypting the derived credentials under a high-entropy key can be viewed as a form of virtual tamper resistance. An example of how the compensating control can be used in a particular derived credentials architecture can be found in [11]. BLOG DISCUSSION We plan to discuss derived credentials more informally on the Pomcor blog at http://pomcor.com/blog/. DISCLOSURE Pomcor has filed patent applications related to the above compensating control and method for protecting derived credentials. REFERENCES [1] ARM. TrustZone. http://www.arm.com/products/processors/technologies/trustzone/index.php. [2] GlobalPlatform. The Trusted Execution Environment: Delivering Enhanced Security at a Lower Cost to the Mobile Market. February 2011. http://www.globalplatform.org/documents/GlobalPlatform_TEE_White_Paper_Feb2011.pdf. [3] Trustonic. TrustZone and TEE. http://www.trustonic.com/technology/trustzone-and-tee. [4] Sierraware. Open Virtualization for ARM TrustZone. http://www.openvirtualization.org/open-source-arm-trustzone.html. [5] GlobalPlatform. Trusted User Interface API Version 1.0. June 2013. Available for licensed download at http://www.globalplatform.org/. [6] B. Kaliski. PKCS #5: Password-Based Cryptography Specification Version 2.0, September 2000. http://tools.ietf.org/html/rfc2898. [7] Gunter Ollman. Want to rent an 80-120k DDoS Botnet? August 2009. https://blog.damballa.com/archives/330. [8] Matthew Broersma. Botnet price for hourly hire on par with cost of two pints. May 2010. http://www.zdnet.com/botnet-price-for-hourly-hire-on-zpar-with-cost-of-two-pints-3040089028/. [9] NIST. Digital Signature Standard (DSS), July 2013. FIPS PUB 186-4. http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf. [10] H. Krawczyk and P. Eronen. HMAC-based Extract-and-Expand Key Derivation Function (HKDF), May 2010. http://tools.ietf.org/html/rfc5869. [11] Francisco Corella and Karen Lewison. An example of a derived credentials architecture. http://pomcor.com/techreports/DerivedCredentialsExample.pdf. [12] Office of Management and Budget (OMB). Safeguarding Against and Responding to the Breach of Personally Identifiable Information. M-07-16. May 22, 2007. http://www.whitehouse.gov/sites/default/files/omb/memoranda/fy2007/m07-16.pdf. [13] George W. Bush. Homeland Security Presidential Directive 12: Policy for a Common Identification Standard for Federal Employees and Contractors, August 2004. http://www.dhs.gov/xabout/laws/gc_1217616624097.shtm.