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
CryptAquireCertificatePrivateKeyto obtain an NCrypt CNG key handle.
In the .NET Framework 4.6, this got a whole lot easier with the extension method
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
CryptAquireCertificatePrivateKeyto create an instance of
CngKey, which then I would pass to
ECDsaCngso I could sign something.
This, also, failed when passing the
CngKeyto the constructor of
Upon examining the
CngKeyinstance 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 interchangable. 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
NCryptFinalizeKeyhas 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
-keysigoption 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
-keysigoption. 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
ECDsaCngclass 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’.
If my site is looking a little different today, that’s because I’ve redone it from scratch. Gone is WordPress, gone is PHP.
Like many others, I’ve started using a static site generator, in this case Jekyll. Static content makes a lot more sense, and a lot of things I wanted to play around with on my previous blog I didn’t get to do because WordPress fought me most of the way.
It also means I can enable brotli on everything.
Finally, there is a real deploy process for this. No more manually crushing images and creating WebP variants of the image by hand. This all happens automatically, behind the scenes.
Making it Work
The site’s content is now on GitHub. On commit, GitHub notifies AWS CodeDeploy, which pulls down the repository to the EC2 instance and kicks off the build. It starts as a gulp task, which runs Jekyll, then compresses images and creates WebP copies. The repository also contains the NGINX configuration, which CodeDeploy copies to the correct location and then reloads NGINX.
AWS CodeDeploy works pretty well for this. It’s a tad difficult to get started with, which was a bit discouraging, but after reading the documentation through a few times it eventually clicked and I was able to get it working correctly.
The migration has left some things missing, for now, such as comments, but eventually I’ll bring those back.
I recently started a project called Authenticode Lint. The tool has two purposes. The primary one being, “Am I digitally signing my binaries correctly?” and two “Are other people signing their binaries correctly?”
To back up a bit, Authenticode is the scheme that Microsoft uses to digitally sign DLLs, EXEs, etc. It’s not a difficult thing to do, but it does offer enough flexibility that it can be done in a suboptimal way. The linter is made up of a series of checks that either pass or fail.
When you sign a binary, the signature is embedded inside of it (usually, there are exceptions). The goal of the signature is to ensure the binary hasn’t been tampered with, and that it comes from a trusted source. The former presents a problem.
If I were to take a binary, and computer a signature on it to make sure it hasn’t changed, then embed the signature in the binary, I just changed the contents of the binary and invalidated the signature I just computed by embedding it.
To work around this problem, there are some places inside of EXEs that the digital signature process ignores. The notable one being the place that signatures go. So the section that signatures go is completely ignored, as is the checksum of the file in the optional header.
Now we have tamper-proof binaries that prevent changing the executable after its been signed, right?
Ideally, yes, but unfortunately, no. There are some legitimate reasons to change a binary after its been signed. Some applications might want to embed a per-user configuration. Re-signing the executable on a per-user basis is to costly in terms of time and security. Signing is relatively fast, but not fast enough to scale reasonably. It would also mean that to perform the re-sign, the signing keys would need to be available to an automated system. That’s generally not a good idea, as a signing key should either be on an HSM or SmartCard and always done by one (or more if using m/n) person manually.
It turns out it is possible to slightly modify an executable after its been signed. There are a few ways to do this, and I’ll cover as many as I know.read more...
Moving along onto page 0x04, we have something different from our last two. It’s also quite short:
That’s it, in its entirety. The al register is the lower 8 bits of the eax/rax register. Let’s demonstrate with LLDB:
register write rax 0x123456789abcdef0 rax = 0x123456789abcdef0 eax = 0x9abcdef0 ax = 0xdef0 ah = 0xde al = 0xf0
OK, so now we know what the al register is. Now its a matter of trying to figure out what the purpose of xor’ing it with 0x20 might be. Let’s see how 0x20 might be special. It helps to look at it in a few different base representations. 0x20 is base-16, and in base-10 it’s 32, and in binary it’s b00100000. Exactly one bit. So what the xor is doing is toggling the 6th bit.
That information alone is enough to Google what the intention is. Before you do though, here’s a hint. Take a look at an ASCII table, and look at the letters in binary form.
Letter Binary A b01000001 a b01100001 B b01000010 b b01100010 C b01000011 c b01100011 etc…
Thanks to the handy layout of the ASCII table, we can see that the xor toggles whether a letter is uppercase or lowercase.
Now we are on to page 0x03. This one has a little bit more going on, but the previous post prepares us for it.
Here is our code:
Our first instruction is sub, which is subtract. It subtracts the second operand from the first operand, and stores it in the first operand. It affects quite a number of flags, too, including CF. We know from the previous post that the following instruction, sbb, pays interest to the CF flag.
x86 uses CF as a borrow flag. Meaning, if you do a-b and a is less than b, then CF is set.
Bringing this back around to our original snippet, we can assume that the second instruction will behavior differently depending on if rdx is less than rax.
Again borrowing knowledge from the last page, we know what sbb will do when both operands are the same and if the carry flag is set or not. Let’s start with the first two instructions.
We have two test cases, so we’ll run through it twice.
Here is a case where rdx is greater than rax:read more...
Previous Page: 1 of 11 Next