Monday, August 8, 2011

Anything goodware can do, malware can do.

Over the past couple years I’ve been repeating these words so often that I’m now calling it Schleiff’s Law. It may seem presumptuous or vain for me to name something after myself, but I got tired of waiting for anyone else to do me the honor.

By goodware I mean software that is neither written nor used with malicious intent. And by malware I mean software that is written and/or used with malicious intent.

Much of my time is spent working on ways to better authenticate computer users to the services they access. It’s now generally accepted that passwords provide only nominal assurance about users’ claimed identity. We generally want to attain better assurance, hopefully without severely degrading usability, and at reasonable cost. The following paragraphs discuss how Schleiff's Law applies to various authentication methods:

  • Soft Certificates

    By soft certificates I mean X.509 certificates containing a public key, where the associated private key is stored on a computer's disk (as opposed to the private key being stored in a hardware keystore such as a smart card). I don't like soft certificates because the private key can be stolen or copied by an attacker, and the compromise is not readily evident to the rightful user of the key. Even if the key is not stolen/copied, malware on the PC could perform the same crypto operations that can be performed by goodware on the PC. Even if the private key is protected by a password, malware (e.g., a key logger) could capture the user-entered password, use the password to unlock the private key, and then operate with the private key for malicious purposes.

  • Hardware-Based Certificates

    By hardware-based certificates I mean X.509 certificates containing a public key, where the associated private key is stored on a separate hardware token, such as a smart card. Such credentials are generally accepted as the most secure for purposes of user authentication. I like hardware-based certificates on smart cards quite a bit. I use one every day in my day job, and I think that after a bit of practice, they are reasonably user friendly. However, even smart cards are susceptible to Schleiff's Law. Whenever a smart card is inserted into a PC's smart card reader, malware on the PC could submit requests to the smart card to perform private key tasks for malicious purposes. Even if the smart card is protected by a PIN, malware (e.g., a key logger) could capture the user-entered PIN, use the PIN to unlock the smart card, and then operate with the private key for malicious purposes. At least one vendor of smart cards and associated middleware provides software to detect inserted smart cards, and prompts the user to remove their smart card after a few minutes. Malware can only exploit a smart card's private key when the smart card is inserted into the smart card reader.

  • TPM-Based Certificates

    By TPM-based certificates I mean X.509 certificates containing a public key, where an encrypted version of the associated private key is stored on a computer's disk, and where the encryption was performed by a key in the computer's Trusted Platform Module (TPM) chip. The only place the private key can be decrypted for use is inside the TPM chip, thus protecting the clear text private key from theft (unless of course the whole PC including the TPM chip is stolen). Because the TPM chip is physically attached to a PC's motherboard, it cannot be removed from the PC, and is therefore always subject to malware that might be running on the PC. Even if the TPM chip is protected by a PIN, malware (e.g., a key logger) could capture the user-entered PIN, use the PIN to unlock the TPM chip, and then operate with the private key for malicious purposes.

  • PC-Based Biometrics

    I admittedly know little about biometrics. However, I think that biometrics relying PC-attached readers and/or PC-resident software are also susceptible to Schleiff's Law. If there's software on the PC to enable biometric capabilities, then malware on the PC could enable the same biometrioc tasks for malicious purposes. Even if the biometrics are stored on a smart card, malware on a PC could interact with an inserted smart card in the same way that goodware could.

  • One-Time Passwords (OTP)

    OTP systems generally rely on some sort of token assigned to a user, and in that user's possession. The token and the OTP management/verification system share a secret key. An algorithm that can be executed at both the token and at the management/verification system operates on the secret and another piece of dynamic shared data (e.g., an event counter, or time). Because the dynamic shared data changes on each use (or every few seconds if time-based), the algorithm produces a different result (i.e., a one-time password) on each execution. OTP tokens can be either soft tokens or hard tokens:

    • OTP Soft Tokens

      By OTP soft token I mean a piece of software running on a PC, or a smart phone, that knows the shared secret and can execute an OTP algorithm to generate one-time passwords. Execution of the software may require the user to enter a PIN. Such a PIN could be discovered by an attacker using keystroke logging malware. Malware could also invoke the soft token software to generate one-time passwords for its own malicious use. Or, the soft token could be stolen/copied from the user's PC (or smart phone) to an attacker's system to be executed whenever the attacker wishes.

    • OTP Hard Tokens

      By OTP hard token I mean a separate hardware token into which the shared secret is loaded, and from which the shared secret can never be extracted. The hard token also keeps track of the dynamic shared data (e.g., an event counter, or time), and can execute an OTP algorithm to generate one-time password values. The shared secret, protected in the hard token, is not susceptible to copying or theft (unless the whole token is stolen).

      • Without PC Connection

        Often hard tokens are in the form of a key fob, and usually with no connection to a PC so they are NOT susceptible to malware running on the PC (or smart phone).

      • With PC Connection

        In some cases OTP hard tokens include a USB connector, and can be connected to a PC. In another case, with Intel's IPT (Identity Protection Technology) the OTP function is provided by an Intel chip on the PC's motherboard. Such cases, because they are not fully air-gapped from the PC, warrant increased suspicion about the token's susceptibility to malware running on the PC.

  • Out Of Band Passwords

    By out of band passwords I mean the delivery of a shared secret to a user on some channel other than to the user's PC. Examples include sending a registration code to a user's home address, or sending a logon code via SMS or text-to-voice to a user's cell phone. Malware running on the user's PC has no access to such codes/PINs/passwords until the user enters the value into the PC, at which point it's probably too late to be of use to malware.

I believe the authenticators most resistant to Schleiff's Law are OTP hard tokens (without any connection to the PC) and out of band passwords. Of course, even though they may avoid Schleiff's Law, they are still susceptible to other attacks, most notably man-in-the-middle attacks.

4 comments:

Paul said...

Nice analysis Marty. I think work has to continue to figure out how to take advantage of hardware based PKI key stores like smart cards and TPM chips in spite of your law, (1) because of the end-to-end strength of a certificate based logon and (2) for the usability advantages. I think we need a triad of
(1) hardware based key stores
(2) trusted boot
(3) application whitelisting
together, to begin with.
TPM chips can give you trusted boot in theory, but don't protect the OS once it is booted, so you need application controls. Application whitelisting alone doesn't protect you from blue pill hypervisor rootkits.

Mike said...

I like the triad and believe the PC industry is motivated and making reasonable progress on providing the 3 components. Unfortunately I wish we could say the same for the mobile industry. There seems to be a complete lack of motivation there, rather obviously because of the different customer demographic. I hear of niche cases, and even rumor of some big players providing a leg or 2 of the triad, but not really a serious effort to address security suitable to enterprise use.

Aidan Herbert said...

Using the TPM for strong machine identity is extremely valuable and narrows down the attack surface. Trusted Boot is a nice concept but where is it practiced and there are may other places to hide malware i.e MBR, applications etc.
Adaptive authentication & web fraud prevention hold alot of promise. Examples include, ability to look at contextual aspects of a transaction request and compare context against a historical behavioral baseline and issue clientless demand for alternate authentication, if significant anomalies are present. TPM-based strong machine identity should be one of the contextual factors.

=marty said...

I agree with Aidan completely.

Regarding TPM (and similar hardware protection of keys): They drastically narrow the attack surface. Without hardware-protected keys, an attacker could steal private keys, and misuse them any time he wished from his own computer. With hardware-protected keys, the attacker can only misuse the keys when the victim's device is powered on (and accessible?). At my day job we're trying to reduce that threat even further, so I like the idea of augmenting TPM with trusted boot and app whitelisting, as Paul suggested.

Regarding trusted boot: Aiden points out the problem with his question, "...where is it practiced". I hope that discussions like this can draw attention to the issue, and result in much broader availability of trusted boot. And going back to Mike's comment, it's especially needed for mobile devices.

Regarding adaptive authentication: At my day job we're increasingly interested in these techniques (e.g., detecting multiple logins from the same account, within a short period of time, originating from geographically disperse locations). I wonder about false positives.