Monthly Archives: September 2013

How to generate and send a timestamp request for Authenticode

When code is signed with a digital certificate the signature can not be relied upon past the validity of the certificate that was used because you don’t know when the signature was applied. If you trusted it beyond that period who knows, the certificate could have been expired and the key posted on a wall somewhere which would mean anyone could have produced that signature.

To address this the concept of time-stamping was added to Authenticode, you can time-stamp something using the time-stamp command in signtool. Here are some steps on how to go about doing that.

 

1. Create the file you will want to timestamp

To do this you will need to find a file on your computer that has an embedded Authenticode signature, on my system that’s skype.exe. You dont want to be messing with its digital signature so make a copy of it:

copy “c:\Program Files (x86)\Skype\Phone\Skype.exe” test.exe

2. Generate a timestamp request

signtool timestamp /t “http://timestamp.globalsign.com/scripts/timestamp.dll” test.exe

3. Verify the timestamp response

signtool verify /v /pa test.exe

This is going to give you some output that looks something like this:

Verifying: test.exe
SHA1 hash of file: 47BC1CD615A52EC31144E8F7A09924ED279C0953
Signing Certificate Chain:
Issued to: VeriSign Class 3 Public Primary Certification Authority – G5
Issued by: VeriSign Class 3 Public Primary Certification Authority – G5
Expires: 7/16/2036 4:59:59 PM
SHA1 hash: 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5

Issued to: VeriSign Class 3 Code Signing 2010 CA
Issued by: VeriSign Class 3 Public Primary Certification Authority – G5
Expires: 2/7/2020 4:59:59 PM
SHA1 hash: 495847A93187CFB8C71F840CB7B41497AD95C64F

Issued to: Skype Technologies SA
Issued by: VeriSign Class 3 Code Signing 2010 CA
Expires: 8/19/2014 4:59:59 PM
SHA1 hash: FA16CD8165DEDF5A79984E7B301323C07C550801

The signature is timestamped: 9/16/2013 10:20:53 PM
Timestamp Verified by:
Issued to: GlobalSign Root CA
Issued by: GlobalSign Root CA
Expires: 1/28/2028 5:00:00 AM
SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C

Issued to: GlobalSign Timestamping CA – G2
Issued by: GlobalSign Root CA
Expires: 1/28/2028 5:00:00 AM
SHA1 hash: C0E49D2D7D90A5CD427F02D9125694D5D6EC5B71

Issued to: GlobalSign TSA for MS Authenticode – G1
Issued by: GlobalSign Timestamping CA – G2
Expires: 9/22/2024 5:00:00 PM
SHA1 hash: 8CE69F5012E1D1A8FB395E2E31E2B42BDE3B343B

Successfully verified: test.exe

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

Hope this helps.

How to generate and send an RFC3161 timestamp with OpenSSL and curl

For me the blog is this odd mix of diary and technical notes, this time I guess the post is more of a technical note — here is a quick guide on how to generate RFC 3161 time-stamps using OpenSSL and curl.

 

1. Create the file you will want to timestamp

 

copy con inputfile.txt

This is my test file.

^Z

 

2. Generate a timestamp request

 

openssl ts -query -data inputfile.txt -cert -sha256 -no_nonce -out request.tsq

 

3. Send the request to your timestamp server

 

curl -k -H “Content-Type: application/timestamp-query” -H Host:timestamp.globalsign.com –data-binary @request.tsq “http://timestamp.globalsign.com”  >inputfile.txt.tsr

 

4. Verify the timestamp response

 

openssl ts -reply -in inputfile.txt.tsr -text

 

This is going to give you some output that looks something like this:

 

Using configuration from C:\OpenSSL-Win64\bin\openssl.cfg

Status info:

Status: Granted.

Status description: unspecified

Failure info: unspecified

TST info:

Version: 1

Policy OID: 1.3.6.1.4.1.4146.2.2

Hash Algorithm: sha256

Message data:

    0000 – 58 df 63 8c 5b bf ff ca-ad 13 c9 6e 93 96 cd 25   X.c.[……n…%

    0010 – 66 5e f1 eb ba 8e 7f 74-6d 65 04 3c 5d ea e4 35   f^…..tme.<]..5

Serial number: 0x2487F5EA8A5A085844ED68A8A7426E07E692E1BD

Time stamp: Sep 17 05:08:38 2013 GMT

Accuracy: unspecified

Ordering: no

Nonce: unspecified

TSA: DirName:/C=SG/O=GMO GlobalSign Pte Ltd/CN=GlobalSign TSA for Standard – G1

Extensions:

It’s that easy.

The weaknesses of fingerprint based authentication

I love security people, were paranoid, were fun, we think outside of the box but we are also human and often times get distracted by dogma and shiny objects. I think this happens a lot when talking about stuff like fingerprint based authentication.

The technology has a very big brother feel to it after all for most people only ever get fingerprinted when you’re registering with the government – hopefully because you want to go on a trip, not because you’re being sent up the river.

Unfortunately attackers don’t usually have this problem, the reason is their goals are more specific – they want in and if they are any good they quickly identify when a path they are perusing isn’t going to be effective so they move on to the next attack vector until they are in or exhaust all their options.

When we look objectively at a fingerprint based authentication solution like is being provided by Apple what are the weakness an attacker is going to go after?

First its useful to understand how these systems usually work, for those of you who have not read my last post here is a quick recap:

A picture is taken of the finger, the picture is converted to the set of features that are extractable from the picture, and those features are stored in something called a template. On use this process is repeated and the features are compared if enough match it must be you. Since its you your password or pin is released to a process to use it on your behalf.

The attacker here starts on the tail end of this process, he sees that in the end we are just taking about a password or pin – if this biometric mechanism is just an option and we can still use the password or pin we have not raised the security bar.

But what if the biometric is releasing access to a key or a strong password instead of your regular old password or pin? Then the attacker would probably start to ask the question how strong is a fingerprint compared to a password? Here is a good post summarizing the effective strength of a fingerprint based biometric – long story short it’s about the same as a six character password.

But wait, why go through the front door if the backdoor is open? For the attacker to execute this attack they have to have physical access to the device right? And the first rule of computer security is that if the attacker has physical access to your device its not your device any longer.

With the device in hand some other things the attacker would want to know are:

  • How the matching works, is it done in software or hardware?
  • What about where the template is stored? How is access to read and write the template accomplished?
  • How is the template secured at rest? Is it readable? Can it be modified?
  • What about where the password and pin is stored? Is it readable? Can it be modified?
  • Does all of this happen in a single piece of hardware or is it shared across multiple devices?
  • If its multiple devices, how do they authenticate each other if at all?
  • How is access to the hardware doing the work authenticated? Is the software authenticated in any way?
  • How about the integrity of the operating system, is there some mechanism that provides guarantees about its running state?

This isn’t an exhaustive list but gives you an idea of the problems here, they are core operating system problems which means that if you use this capability on a jail-broken device you are probably reducing your security above and beyond where you would have been otherwise.

As you can probably see its likely that the security of this solution isn’t going to be based on how good the sensor is at detecting fakes but how the overall system itself was architected.

So what do I think about the use of biometrics given the issues discussed here? I actually believe its possible to design, build and deploy a system that is reasonably secure based on this technology and that if done right you can measurably improve the security for the user.

It doesn’t need to be perfectly secure to do that either, you simply have to get the user to the point where he you can use long and strong passwords and not the sort of thing that they normally use:

clip_image002

For example in Windows one might rely on the following:

  1. UEFI secure boot ensures the boot loader is authenticated and non-tampered.
  2. Windows Secure boots only authenticated non-tampered code is loaded.
  3. Driver signing ensures all drivers are authenticated and non-tampered.
  4. Bitlocker ensures the disk is encrypted and cannot be modified outside the scope of the machine.
  5. The TPM ensures the Bitlocker keys are secured from the average attacker.
  6. Password Policies ensure passwords are sufficiently long and complicated.
  7. Reversibly encrypted passwords are stored using a strong key hierarchy where the root of the hierarchy is protected by the TPM.
  8. Fingerprints make it possible for the user to successfully log on with the long complicated passwords efficiently.
  9. Use sensors with reasonable fake finger and liveness tests.

There are still attacks in the above configuration but the low hanging fruit have been nailed and deploying a solution like this likely raises the bar an attacker has to cross to successfully exploit your environment.

Is it as good as other mechanisms (for example smart cards) certainly not, but better than what people actually do in production environments today? Yes, very likely.

Is this for everyone? Certainly not; but for many it would be a step up.

I am not familiar enough with the security architecture of the iPhone and OSX to say if the same sort of protections exist, they may – but without them one thing is for sure the “gummy bear attack” is probably the least of your worries.

Thoughts on Apple and fingerprint based biometrics

Yesterday Apple finally confirmed what their acquisition of Authentec was all about, integrating fingerprint based biometrics in the iPhone. This was not exactly a surprise but its one thing to know they were going to do it and another to see how they went about it.

Details are still a little light on the implementation and there appears to be a lot of speculation about how they did things but I have not seen any one provide a reasonable write up of how this technology works, what its limitations are and the value it has.

Let’s start with what these things actually do, plain and simple a fingerprint sensor is a camera. It takes a picture of the structure of your finger, some sensors look just at the surface, some look a little below the surface. Different sensors use optical capture, while others use capacitance and other mechanism but regardless of all of this they all take a picture of your finger.

This picture is then processed looking for “minutia”, the little details that make that image unique (ridges, valleys, swirls, etc.). These are then mapped into something commonly called a template, it is this template that is stored.

clip_image001

The important thing to take away here is when you are enrolling the biometric sample itself isn’t actually stored, it’s simply not needed.

Once you are enrolled the same process happens (capture image, identify minutia, create template) except instead of storing it this time it is compared to the stored template. Now each time you log in you present your finger slightly differently, this means that not all of the same minutia will be seen in every captured image.

As a result the matcher has to guess if the person is you or not based on how many minutia it sees in common with the stored template.

This works fairly well when doing what is referred to as verification, this is when the sample is compared to just one sample as is probably the case when dealing with a device like the iPhone. When doing identification though (the one to many variant) there are a number of other problems to consider; I won’t discuss that here.

Now each of the image capture approaches used by sensors have different security properties; for example with optical sensors I have seen people lift the fingerprint from the sensor glass itself and re-use it.

According the press conference sensor used by the iPhone looks sub-dermally, the primary thing this helps with is resilience to small cuts and scrapes that could push the threshold authentication done with biometrics over the edge making it impossible to match you – it also does provide some security value in that the characteristics are not exactly the same ones you leave everywhere.

Now the good sensors also have logic in them to detect fake fingers, some of these are simple live-ness tests while others look at the characteristics of the flesh itself. For example a swipe sensor may look at the elasticity of the finger as it is dragged across the sensor.

One of the real problems here is that when you are buying a device with one of these sensors on them you have zero clue how good the mechanisms (if any) they use are. In my case I went and bought several fingerprint handgun boxes that had biometrics cracked them open to see who manufactured the sensor and contacted the heads of the engineering departments at the sensor companies (that I happened to know due to my work) and I had them help me figure out which device had the best fake finger detection so I knew which one to use.

In the case of the Apple sensor again we have no clue what kind of fake finger / live-ness tests they have implemented. I am sure thanks to security researchers once the devices ship we will found out how effective they are dealing with this in short order.

But what happens when the matcher decides there’s a good chance it’s you? It releases a “secret” and what is that secret you ask? Well in most systems it’s actually the password the user would have entered had the sensor not been there.

That’s right, all of the above magic to make entry of the password easier. This isn’t actually a bad thing, but again it depends on how it was implemented.

As a practical matter people can remember 7-9 character passwords, these passwords get re-used or trivially modified which greatly reduces their effectiveness. By using biometrics to gate access to them we can replace that short junky password with a longer key, in the process we can greatly increase the security of a system as a result.

Here is the thing — it doesn’t sound like that’s what they have done here, it seems they have applied the biometric to the four digit numeric pin and made the application store password protected by that pin. I say this because (according to the New York Times) which you will have to set the pin still for recovery purposes. If this is the case (and until we see them we will not know) the biometric is no more secure than the four digit pin its gating access to.

It could still have some value though, for example according to the press conference around 50% of iPhone users set the pin if this can meaningfully increase that number on aggregate were in a better world.

One more troubling thing for me as I think about the Apple integration is that they are one of the most secretive tech companies out there and were not likely to hear the answers of how they have handled the above issues or any others.

The origin of the Windows Biometric Framework

One of the projects I was responsible for when I was at Microsoft was the design and delivery of the Windows Biometric Framework. This was actually one of my favorite projects during my entire tenure at the company.

What most people don’t know is the feature was a very late addition to Windows 7, an analysis of the crash data sent by clients to Windows showed that right after Video Cards these fingerprint readers were one of the largest sources of the “Blue Screen of Death”.

Something else most people don’t know that this was not the first attempt to provide a platform for biometrics into Windows, the prior attempts failed for various reasons but they did not have the same data we had – we knew these devices that were barley used were creating a bad experience for anyone just because the OEM decided to include these sensors as a differentiator.

To fix this a stellar team of senior engineers were re-assigned from other projects and began work almost halfway through the Windows 7 release cycle. Our goal was to make it possible for these devices (and in the future other forms of Biometrics) to work well with the minimal amount of vendor code.

You see these devices need to respond really quickly, especially swipe sensors because they take a picture of your finger as you drag it across the sensor and that data needs to get to a number of components very quickly to make a workable user experience. For this reason the sensor manufacturers all thought they needed to be in kernel, and since most driver developers have only been doing driver development for a few years they did a really bad job of it which resulted in the blue screens.

The value proposition of this project for the vendors was that ultimately they wouldn’t need to write so much software to get their sensors to work, for some this was seen as a positive – especially the new entrants since they didn’t have as much software. For those vendors with complete software suites, they were less thrilled in that a driver framework of any kind places architectural restrictions on the way you build things and since they didn’t get the support calls they didn’t really care that much about the crashes their software caused.

Despite this nearly every biometric vendor begun work on new driver’s client software based on this platform that was being developed at almost the same time they were writing their components. Every vendor who was in the first round of development made significant time investments to make the platform a reality.

The software team at Microsoft also executed amazingly, I am confident that I will allways think of this group of individuals as one of the best I worked with at the company.

In the end the platform made it out the door with more features than we had originally hoped with all the major vendors on board and by the general availability to OEMs people were ready to support real customers.

The late start did mean OEMs had to work very hard to get the new device drivers in their initial images, they had very little runway to do so but several did and those that did not at first got their revised images out shortly later.

This new model delivered a kernel mode and user mode driver model that significantly reduced the amount of software that was needed to get one of these devices working in Windows, we delivered a test suite that helped ensure the devices and their drivers worked reliably. And we were even able to deliver a framework for use, management, group policy, and a hook for enrollment.

The combination of the above meant that we essentially eliminated the historic problems these devices caused, improved the security of how they worked when integrating with windows, made them more supportable and simply work well.

The team went on to work on some very cool additions, many of the team changed but some remained and the work that we began after the “freeze” in the Windows 7 release cycle ultimately found their way out in Windows 8/8.1 – I hope the rest of the things this team were doing find their way out someday soon also.