• Authenticode and ECC

    While HTTPS / TLS have been making great strides in adopting new cryptographic primitives, such as CHACHA, x25519, and ECC, another place has remained relatively stagnant: binary signing.

    While many platforms deal with binary signing, I deal the most with Authenticode which is part of the Windows operating system. I thought it would be an interesting experiment to sign a few things with an ECDSA certificate and release them in to the wild.

    First I needed to find a CA willing to give me an ECDSA Authenticode certificate. DigiCert was happy to do so, and they offered it to me for no charge as part of their Microsoft MVP program. They were very helpful by making it very easy to get an ECDSA Code Signing certificate.

    ECDSA Signing Certificate

    Safe Keeping

    Normally I keep my signing certificate on a hardware token, a Yubikey 4. I’ve had some good success with the Yubikey for this purpose. I would generate a CSR from the Yubikey, it would keep the private key, and I would get a certificate issued with the CSR. The Yubikey is also able to do all of this for ECDSA / P-256 certificates. I was even able to load the ECDSA certificate that was issued on to the Yubikey, and my Mac recognized it immediately, as did OpenSC.

    Windows however was a bit different. Normally when you insert a SmartCard on Windows, it will read the public certificate from the SmartCard, automatically import it in to the Personal certificate store, and link-up the private key to the SmartCard.

    That did not work with an ECDSA certificate. The Windows service that is responsible for this, “Certificate Propagation”, doesn’t handle ECDSA certificates. Manually importing the certificate doesn’t work either, because the certificate is missing the “Key Container Name” link back to the SmartCard. It’s possible to repair this link, but it needs to be done every time the SmartCard is re-inserted.

    For purposes of this experiment, I decided to forgo the SmartCard and instead import the private key in to the Windows Key Container store, and force it to prompt me for a pin every time it’s used to sign.

    Signing Pin Prompt

    Signing

    Signing with the ECDSA certificate worked as expected. signtool had no problems signing with ECDSA, and Windows was happy with the signature.

    There was nothing different that needed to be done here. My Authenticode Lint tool was also happy with the ECDSA signatures. This was a little exciting to see an ECDSA certificate “work” in Authenticode Lint. To-date all of the ECC capabilities of it have been tested with self-signed certificates.

    Distribution

    Everything started to go wrong here. While Windows was happy with my signatures, many other things had a problem with it.

    The first were Antivirus systems. AV applications take in to account signatures to determine the trustworthiness of the application. Of the few that I was able to test, none of them recognized the binary as signed. This tripped up Windows SmartScreen, which told me my own application wasn’t signed, seemingly confused by the ECDSA signature.

    Likewise “UTM” firewalls didn’t like the binaries, either. These are firewalls that do on-the-fly virus scanning as files are downloaded and block it if it considers it unsafe. Depending on how the UTM is configured, it didn’t like the ECDSA signatures, either.

    This is easy enough to fix by mixed signing, which is a scarce-to-nonexistent practice with Authenticode. Most applications are already dual signed, once with a SHA1 file digest, and also with a SHA2 file digest. To make ECC work, you would need a third signature. The ECC one can’t take the place of the RSA+SHA2 one because then those poorly behaving applications will ignore the ECC+SHA2 one and treat it as only RSA+SHA1 signed.

    Three Signature File

    Lastly, some Antivirus vendors think even the presence of an ECDSA signature is enough to warrant flagging it, however most of these scanners seemed to be small companies. The bigger-name scanners did not have a problem with the presence of an ECDSA signature.

    Conclusions

    I understand why ECC hasn’t taken off with code signing. RSA has a lot of inertia and there is little reason to move to something else if RSA “just works”.

    If for whatever reason you want to use ECDSA to sign binaries, you will likely need to continue to sign with RSA (and RSA being the “root” signature).

    Motivations

    I mostly did this to solve my own curiosity. ECC does have a number of benefits, though. It’s generally considered stronger and more compact. Authenticode PKCS#7 also stores the whole certificate chain for the signature. If the chain were entirely ECC (alas I was not able to get an ECDSA cert that was issued by an an ECDSA intermediate) then it could shave a few kilobytes from the size of the signature.

    If you need stronger but can’t afford the complexity of ECDSA, then RSA-4096 is the way to go.

  • Password History

    A few tweets have started making the rounds about how companies must be doing password security wrong because they seemingly do magic. Let’s start with the simple one, password history. Here’s some musings on how I think some magic could be implemented without a huge loss of security.

    This is pretty straight forward to solve. Keep a history of the hashes. When the user enters a new password, take the password they just entered, and see if it matches any of the password hashes in the history.

    A password hash typically consists of a digest and a salt. I’d strongly recommend that each password in the history have their own salt, so don’t reuse salts when a user types in a new password. So a password history table might look like this:

    salt digest version
    salt1 digest1 1
    salt2 digest2 1
    salt3 digest3 2

    And the user enters a new password because they want to change it. The check process would look something like this:

    hash_alg_1(salt1 + newPassword) == digest1
    hash_alg_1(salt2 + newPassword) == digest2
    hash_alg_2(salt3 + newPassword) == digest3
    

    If any of those are “yes”, then they’ve used a password in their history.

    In real life, you are probably using something like bcrypt. Many bcrypt libraries put the salt, digest, and “version” (work factor) in to a single output separated by dollar signs. They also provide convenience APIs to make the verify process simpler. You give it a previous bcrypt output and a plaintext password, and it knows how to use the salt and the work factor to see if the hashes match.

    This approach typically works pretty well. I’d also caution how long you would want to keep password history. Too long might mean keeping around hashes that are weak. Let’s say you were using bcrypt(8) a few years ago, but moved to bcrypt(10). Keeping that bcrypt(8) password indefinitely means you’re storing passwords with less-than-ideal strength. If the password history is ever stolen and the history is weak, then you might be giving the attacker clues as to a password the user is using on another site, or their password habits.

    If you ever need to drastically change the password hashing scheme because it’s broken (straight, unsalted MD5 for example) I’d purge the history altogether. It’s too much of a liability to have lying around.

    The trickier one is fuzzy password history, but it can be done in some limited ways. The trouble with hashes is, they either match, or they don’t. There is no good way today to see if two password hashes are related to each other.

    You can however tweak the input of the plaintext when checking history.

    Let’s say the user’s old password is “I<3BillMurray11” and they change it to “I<3BillMurray12”. A site might say this password is too similiar to a previous password. You might quickly come to the conclusion they are storing passwords in plain text, or reversable encryption.

    The site also could simply try a few heuristics on the input. It’s well known that when a password needs to change, users might cop-out and just increment a number at the end. So when the user types in a new password, check the history. No matches? Well, does it end with a number? Yes? decrement it and try the history again.

    You are certainly limited to how much fiddling you can do like this. Good password hashing schemes like bcrypt are by-design not fast (to counteract offline brute force attacks). So checking hundreds of things is quite slow.

    You can however use this to try a few of the worse offenders. Incremented trailing numbers is a very common one, same with addign a letter. Try chopping off a letter from the password end and see if it matches the history. Password history for a user should also reasonably fit in to memory, so doing these checks in parallel is doable, too.

    Those are just some examples, and things that I think security engineers can reasonably implement. Unfortunately when things like this do get implemented, there is often suspicion and cries of plaintext problems.

    That’s not to say that there aren’t sites that do store passwords in plaintext or symmetric encryption. Those sites are problematic, and need to get fixed. If the password history fuzziness seems too clever, such as Levenshtein or Hamming distance, then that might indicate bigger problems.

  • How to use SecureString in .NET

    Don’t. Probably.

    Okay, maybe I should elaborate. The SecureString class in .NET has been a source of a lot of questions on StackOverflow. It has the word “secure” in its name, “secure” seems good, so we should use SecureString!

    SecureString is a managed wrapper around the DPAPI APIs in Windows. The idea of SecureString is that it is a string that is in memory, considered sensitive, and you don’t want it to be exposed in memory leaks or a memory dump, or in any other scenario where a string in memory is undesirable.

    There are a number of problems with this though.

    Construction

    Constructing a SecureString in the first place is difficult. A common question on StackOverflow is “How do I create a SecureString?” an invariably, an answer like this comes up:

    //Don't do this!
    var secureString = new SecureString();
    var password = Console.ReadLine();
    foreach(var c in password) {
        secureString.AppendChar(c);
    }
    

    This copies the string into a SecureString. Well, except for the problem that the original string, password, is still in memory, clear as water. Since strings in .NET are immutable, “zeroing” them results in trying to do something ugly, like pin a managed string and zero it with unmanaged code by writing over it. In the native world, that is a perfectly valid thing to do. In .NET, that might not always be the case, such as if the string was interned. The CLR expected to be in control of a string’s memory, and stomping on it can do unexpected things.

    You can reasonably create a SecureString if you use Console.ReadKey in a loop, or have low-level access to a Win32 password box. WPF even goes so far as doing this out of the box for you by providing a SecureString property on PasswordBox.

    In web applications, it’s downright infeasible to use SecureString on content that came from a web browser. You couldn’t have a <input type=password> on a page and be able to put that in a SecureString, securely. The ASP.NET pipeline has done so much buffering, copying, and shuffling around of the request’s body that there is no practical way to remove it from the request body.

    So let’s say you are able to construct a SecureString, securely. Now what?

    Consuming

    There are very, very few APIs in the .NET Framework that know how to work with a SecureString. NetworkCredential is the big one, which is accepted in a few places, like LdapConnection, WebRequest, and a few others.

    NetworkCredential is actually interesting because it prefers storing things in SecureString, if the platform supports it.

    Even the .NET Framework can’t always use SecureString. It might just end up calling InternalGetPassword on the NetworkCredential, which will just make a managed copy of the string, anyway, left to be cleaned up by the garbage collector.

    SecureString does work well, relatively speaking, if you are working with an API that wants a string as a pointer. In that case, Marshal.SecureStringToGlobalAllocUnicode (substitute for the allocator of your choice) may be useful, as long as you call Marshal.ZeroFreeGlobalAllocUnicode when you’re done. This will almost never be the case. In these situations, you need to carefully put your SecureString back into managed memory, do something useful with it without it getting copied out of control, then clean everything up. This is what’s involved with say, hashing a SecureString.

    var secureString = new SecureString(); //Assume has password
    var buffer = new byte[secureString.Length * 2];
    var ptr = Marshal.SecureStringToGlobalAllocUnicode(secureString);
    try
    {
        Marshal.Copy(ptr, buffer, 0, buffer.Length);
        using (var sha256 = SHA256.Create())
        {
            var hash = sha256.ComputeHash(buffer);
            //Do something useful with the hash
        } //Dispose on HashAlgorithm zeros internal state 
    }
    finally
    {
        Array.Clear(buffer, 0, buffer.Length);
        Marshal.ZeroFreeGlobalAllocUnicode(ptr);
    }
    

    Here we copy the SecureString into native memory, copy it in to managed a managed byte array, hash it, then clear the managed array. Using Array.Clear with overwrite the contents of the array. This however implies that we trust what ComputeHash is doing with the contents of the array though. It could be creating copies of the byte array without us knowing about it. That depends on the implementation of SHA256. SHA256Managed does a reasonable job of not doing this, and disposing of the object will clear some internal arrays, also using Array.Clear.

    In case it wasn’t obvious, our secure string is naked during this process. It might only be a few moments, but that is the fundamental truth of SecureString. The only way to do anything useful with it is to copy it’s clear form in to memory for controlled, short periods of time. The practical use of this is it means memory has to be examined at just the right moment for it to be in cleartext.

    So now we have to think about what we’re protecting against. If we are trying to protect against a rogue process being run by the user, remember that a process cannot read another process’s memory without the PROCESS_VM_READ permission, which is usually reserved for elevated processes and debuggers.

    If the process is an adminstrator, then it’s already game over. SecureString is the least of your worry. With Administrative permissions, someone could simply just hook your process and inject code to call SecureStringToGlobalAllocUnicode anyway.

    None of this begins to even touch on other problems, like paging to disk. It is ever-so-slightly possible that the SecureString’s contents, while unprotected for those brief moments, gets paged to disk. Or the system gets hibernated and written to the hibernation file on disk. It’s much more difficult to expunge data from disks.

    To summerize, the security benefit offered by SecureString is very small in contrast to the level of effort to actually use it. There are probably much more sensitible things to focus this effort on that will yield much better protection for your users.

  • Re-examining HPKP

    Not too long ago I wrote about HTTP Public Key Pinning and adopting it on a website. Now that I’ve had the opportunity to help a few websites deploy it, I thought it would be worth re-visiting the subject and looking at what worked, and what didn’t.

    The first discussion that came up was deciding whether or not it is a good idea. It’s easy to say, “of course”. HPKP is a security feature, we want security, therefore we want HPKP. But HPKP comes with some costs. Many of those costs can be reduced by doing other things, but it boils down to having excellent posture around key management, process, and documentation. It’s easy enough to turn HPKP on a blog, but doing so with several members of operations, security, and developers, it is considerably more difficult. The penalties are unforgiving. At the worst, you may end up with a completely unusable domain. So before you jump right in and start hashing public keys, look at the long term viability of being able to do this, and build tools and process around it to make it work.

    Given that HPKP has considerably high risk of getting wrong, it’s worth getting a solid understanding of what it does, and does not, address. You may come to the conclusion that the risks outweigh the benefits, and time should be better spent on other ways to improve security.

    Deciding to move forward, there are a number of things that needed to be discussed. The first thing that came up was what to pin. Some suggest pinning an intermediate certificate, while others suggest pinning a leaf. My recommendation here is pin only what you control. For most people, that means the leaf. For very large organizations, you may have your own intermediate certificate. Some recommend pinning a CA’s intermediate to reduce the risk of losing keys. In this scenario, you would just need to re-key your certificate from the same certificate authority. The downside to this is CA’s deprecate intermediate certificates, and there is no guarantee they’ll use the same key in a new intermediate certificate. If you do decide to pin an intermediate, I would recommend one of your backup pins be for a leaf.

    Then there was the matter of backup pins. User agents require that a backup pin is available before it will enforce pins. I would recommend more than one backup pin, and providing some diversity in the algorithm that is used as well as the key size. For example, if I intended to pin an RSA-2048 key, my backup pins might be another RSA-2048, and an ECDSA-P256. The different algorithm gives you an option to immediately move to a different algorithm in the wake of a discovery, such as finding out that RSA is broken, or that the NIST curves in P256 have weaknesses. Even if nothing like that happens, which it probably won’t, it also gives a straight forward path to increasing key sizes, which is a natural thing to do over time.

    Having a backup pin for the same algorithm allows recovery from the loss of a key, or exposure of the private key without changing the algorithm used. Moving from one algorithm to another, like RSA to ECDSA, will carry some compatibility risks with older clients. Having a backup pin of the same key length and algorithm at least ensures you can recover without the additional burden of investigating compatibility.

    Lastly there was the matter of testing backup pins. I strongly recommend using Report-Only first when deploying HPKP, and testing a failover to each and every backup pin. While doing this, I ran in to a situation where a backup pin wasn’t working. It turned out that the SHA256 digest of the SPKI was actually a digest of the string “File not found”.

  • ECDSA Certificates and Keys in .NET

    It’s not uncommon to need to sign something with the private key of a certificate. If you’re using RSA or DSA certificates, that’s been a fairly straight forward process with the .NET Framework. If your certificate was an ECDSA certificate, this was not a straight forward process. You often had to fall back to p/invoke using CryptAquireCertificatePrivateKey to obtain an NCrypt CNG key handle.

    In the .NET Framework 4.6, this got a whole lot easier with the extension method GetECDsaPrivateKey.

    I did run in to a problem with it though. I was getting an exception:

    System.ArgumentException: Keys used with ECDsaCng algorithm must have an algorithm group of ECDsa.

    I did a lot of double checking of the certificate, yes the certificate had an ECC key in it and the algorithm parameters explicitly defined the P256 curve for ECDSA. What gives?

    I decided to fall back to old tricks and use CryptAquireCertificatePrivateKey to create an instance of CngKey, which then I would pass to ECDsaCng so I could sign something.

    This, also, failed when passing the CngKey to the constructor of ECDsaCng.

    Upon examining the CngKey instance itself, CNG believed the key was ECDH, not ECDSA. This was getting bizarre. Strangely enough, I had another certificate where this worked perfectly fine and CNG was happy to announce that the algorithm was ECDSA.

    ECDH and ECDSA keys are interchangeable. You probably shouldn’t use the same key as a key agreement (ECDH) and signing (ECDSA), but ultimately they are just points on a curve. Yet somehow, CNG was making a distinction.

    We can throw out the certificate itself being the source of the problem. If I opened the private key by name, it still believed the key was for ECDH. Clearly, this was an issue with the private key itself, not the certificate.

    The cause of all of this mess turned out to be how the CNG’s key usage gets set. Every CNG key has a “key usage” property. For an ECC key, if the key is capable of doing key agreement, CNG decides that the key is ECDH, even though the key is also perfectly valid for signing and verifying.

    Now the question is, how do we set the key usage? Key usage needs to be set before the key is finalized, which means during creation. It cannot be changed once NCryptFinalizeKey has been called on the key.

    My certificate and private key were imported as a PKCS#12 (.pfx) file through the install wizard. It’s during this process that the key’s usage is getting set.

    After a bit of trial and error, I determined that setting the keyUsage extension on the certificate does not matter. That is, if the keyUsage extension was marked critical as set to signature (80), the CNG key would still get imported as AllUsages.

    Eventually, a lightbulb came on and I examined the PKCS#12 file itself. It turns out that the PKCS#12 file was controlling how the private key’s usage was being set.

    A PKCS#12 file contains a number of things, one of them is a “key attributes” property. If you use OpenSSL to create a PKCS#12 file from a certificate and private key, OpenSSL won’t set the key attributes to anything by default. If you create the PKCS#12 file with the -keysig option then the import wizard will correctly set the key’s usage. If you create the PKCS#12 file with Windows, then Windows will preserve the key usage during export when creating a PKCS#12 file.

    Let’s sum up:

    If you have an ECDSA certificate and private key and you create a PKCS#12 file using OpenSSL, it will not set the key attributes unless you specify the -keysig option. So to fix this problem, re-create the PKCS#12 file from OpenSSL with the correct options.

    Alternatively, you can wait for the .NET Framework 4.6.2. In this version of the framework, the ECDsaCng class is happy to use a ECDH key if it can. This is also the only option you have if you really do want to have a key’s usage set to ‘AllUsages’.