Join 3,440 readers in helping fund MetaFilter (Hide)


Secure AES challenge-response.
May 4, 2011 7:21 AM   Subscribe

How do I securely implement a cryptographic challenge-response in software if the software needs my AES key to create the challenge?

I have a YubiKey USB device that supports challenge-response queries [pdf].

Conceptually, I'm under the impression that the cryptographic "challenge" is created with the AES key. Assuming an offline software application needs to challenge the device, how can the AES key be available to the software without compromising system security?

It seems like the AES key needs to be either hard-coded into the application or stored in a local database or config file. I must be missing something, though.

Note: I'm not actually going to be the programmer implementing this, I just need to understand the conceptual framework under which this scenario would be secure.
posted by odinsdream to Computers & Internet (12 answers total)
 
Each key is more accurately a key pair, consisting of a public key and a private key. It's only the private key that must never be exposed. You can send the public key around unsecured, hardcode it into your applications, etc.
posted by Paquda at 7:30 AM on May 4, 2011


Isn't AES a symmetric (private key only) algorithm?
posted by jangie at 7:33 AM on May 4, 2011


It seems like the AES key needs to be either hard-coded into the application or stored in a local database or config file.

Right, if you're talking about a symmetric encryption scheme here, so both sides need to keep the secret key. What exactly are you trying to verify with this scheme? If it's possible to use a different secret key for each YubiKey, for instance, you might not care if any single key leaks because a local machine is compromised.

Each key is more accurately a key pair, consisting of a public key and a private key. It's only the private key that must never be exposed.

As far as I can tell this YubiKey system is not using a public key encryption scheme, so although this kind of encryption obviously exists I don't think that's what's being discussed in the question.
posted by burnmp3s at 7:35 AM on May 4, 2011


I think the OP might have just been wrong about AES being used for the challenge-response. From the PDF linked to (which I only skimmed), it looks like an HMAC algorithm is used.
posted by Paquda at 7:37 AM on May 4, 2011


Yes, this is symmetric encryption, not public-key. YubiKeys have a few different modes, the most popular being a second factor authenticator for server-based applications. Clearly the server in that case has the AES key to decrypt the key's OTP.

Each key does have a separate AES secret key, but if the application needs to verify multiple keys it'd have the entire AES secret list somewhere internally.
posted by odinsdream at 7:38 AM on May 4, 2011


Paquda; HMAC is an option - does that solve the issue of the application needing to store secret information? If so, how?
posted by odinsdream at 7:39 AM on May 4, 2011


The device has a secret key and has the ability to compute a hash value using the private key over a piece of information an outside application supplies. The outside application application can compare the resulting hash to an expected value (supplied in this case in the user guide) to confirm that the correct private key was used. The outside application never needs to know the private key. Looks like I was wrong to use the public key/private key terminology, sorry about that--theres no public key, just an expected hash value.
posted by Paquda at 7:46 AM on May 4, 2011


Each key does have a separate AES secret key, but if the application needs to verify multiple keys it'd have the entire AES secret list somewhere internally.

What is the point of this scheme then though? Are you trying to tell valid YubiKeys from fake ones? Do you not trust the person running the offline machine (like in a dongle situation for a copy-protection scheme)?
posted by burnmp3s at 7:48 AM on May 4, 2011


Do you not trust the person running the offline machine (like in a dongle situation for a copy-protection scheme)?

It's not necessarily that the users are untrusted, but rather that having a list of the AES secrets stored with the application could lead to them being copied by untrusted parties and used to create false keys that the application would trust.

The point of the scheme is for the application to be able to validate the presence of legit keys, and distinguish each legit key from the others.

Conceptually, I can see how this works securely with the exception of storing the secret in the application.
posted by odinsdream at 8:12 AM on May 4, 2011


It's not necessarily that the users are untrusted, but rather that having a list of the AES secrets stored with the application could lead to them being copied by untrusted parties and used to create false keys that the application would trust.

If that's the case, then Paquda's advice above is good. You generate a bunch of challenge/response pairs using a secret key on some secure machine, and include a random set of those with the software. That way if someone pulls the vectors out of one client, a fake USB device can only trick that single client (because other instances will be using different challenges). Note that this only works if you really can distribute those vectors for each secret key randomly for each application instance, and if you have to support a lot of different secret keys that might not be feasible.
posted by burnmp3s at 8:20 AM on May 4, 2011


Please read this before you continue:

Challenge-response mode - FAQ (Yubico)

If you use the HMAC-SHA1 mode do not use a fixed set of challenges because the responses from the Yubikey device will be identical. Hence anyone who wants to mimic the Yubikey will just need to "replay" the responses back to you, hence the term "replay attack":
Why implement both algorithms ? Is one better than the other ?
Depending on the setting, both have different benefits. The Yubico OTP generates a unique OTP even if the challenge vaires as the counters and random field is generate internally in the Yubikey. The HMAC-SHA1 operation by nature generates the same response every time for a given challenge. Software applications that repeatlvely verifies the presence of the Yubikey should use the HMAC-SHA1 operation with a counter or a random number as challenge as this gives unlimited usage time. With the Yubico OTP algorithm, there is a chance that a programmatic application could cause the counters to wrap, which is not practically possible in normal OTP usage.
Moreover, I'd highly recommend you read (for free) chapter 2 of "Security Engineering, so that you can give yourself a basic grounding in cryptographic protocols. You should find the section on challenge-response protocols in this chapter quite enlightening!
posted by asymptotic at 8:52 AM on May 4, 2011 [5 favorites]


Note that this only works if you really can distribute those vectors for each secret key randomly for each application instance, and if you have to support a lot of different secret keys that might not be feasible.

This makes a lot more sense, and it's feasible for our application which checks in with a server every so often. We could send a new set of challenge/response pairs at that time.

Thanks for the discussion so far - this has been very helpful!
posted by odinsdream at 9:41 AM on May 4, 2011


« Older Can I prepare and save this bi...   |  Where can I find statistics on... Newer »
This thread is closed to new comments.