Category Archives: Thoughts

PiperWallet First Impressions

1 Reply

So I just got my PiperWallet. For those of you not yet familiar with it the PiperWallet is an open-source hardware bitcoin wallet based Electrum running on a RaspberryPi paired with a built in thermal printer in what looks like a 3D printed chassis.

The basic idea is that managing cold wallets is hard and it doesn’t have to be.

Even though I have only started to play with the device overall I am impressed. Here are my initial observations:

  1. It was packaged well considering the volume in which they are produced;
  2. The quality of the casing is also good considering the volume;
  3. The cut outs are a little rough and are larger than the connectors they expose;
  4. The primary “indicator LED” that is used to show that the device is booting is not terribly bright;
  5. Without reading the instructions (or waiting a sufficiently long time) it’s not  obvious when the device is ready;
  6. The print button LED is bright and of excellent quality;
  7. There is no positive feedback when the print button is pressed.

So far I am happy with the purchase though I need to do some more playing with it before I make any final conclusions.

With that said here are the things I think I would change if it were my product:

  1. Make the serial numbers on the paper wallets randomly generated; you un-necessarily leak information by using monotonically generated serials;
  2. Add tamper evident seals to the casing so that if the device is opened during shipping it is obvious;
  3. Add tamper evident seals or “plugs” over the ports exposed on the device, possibly even dummy plugs with seals so its clear nothing happened to the device as part of shipping;
  4. Add per-device fixed wallet keys to be used as a serial number to the back of each case (there is a wallet address but I believe this is an address of the Piper team);
  5. Use per device passwords shipping them on a form similar to the one I provided here;
  6. Replace the indicator LED with one with a similar brightness and quality to that used in the “print button”;
  7. Add a small LCD display that can be used to provide real-time feedback and status so it’s easier to use when headless;
  8. In the documentation included have the steps to verify what software is running on the device along with hashes to do so.

Verifying a Bitcoin Wallet Address

Leave a reply

Before sending someone a large sum of money on the internet via a irreversible transaction you better make sure you are sending the funds to the right address.

There are a few ways to go about doing this and depending on who you are sending funds to, how accessible their keys are and what the capabilities and behavior of their wallet software is you may need to choose different solutions.

Have the recipient sign a message using their wallet key

If we assume the recipient has the key associated with the target wallet online (aka not in cold storage) and that that the software they use for that wallet supports message signing with wallet keys this can be a viable option.

Unfortunately there is not currently a standard for the format of signatures using bitcoin keys with that said thankfully there appear to only be two common formats in-use today.

The first format being in-essence no formatting; client simply present you the three values you will need to verify a message and you do with them as you see fit, for example:

  • Wallet Address: 18neTpQ5MWnXg4n4rpoK5TgxXjEVcg2MYR
  • Message: [email protected] – my voice is my passphrase authenticate me
  • Signature: G0d6BnQem1gT4nd9esfsEyn1k/GfYAxDkNJmkNvmz8wCOI2Ncw9DvIcyP7OJcEvWbUHQNIBFK3V8wYdnhEFhYHI=

This format leaves a little be desired. For one you have to pass these values independently and then you also have issues around introduction of white-space which can invalidate signatures.

There is another increasingly common format that leverages ASCII armor and some codified rules to address these issues. This style of formatting originated in a project called Privacy Enhanced Mail (PEM), it was one of the first proposals for how to sign and encrypt mail on the Internet and was later adopted by PGP (RFC https://tools.ietf.org/html/rfc4880).

But don’t confuse this format with these other formats they follow some different rules when it comes to encoding.

What this means is that depending on the implementation of the wallet software the recipient uses you may not be able to validate the signature they produce without some manipulation of the text.

As for what this format looks like, its fairly straight forward:

-----BEGIN BITCOIN SIGNED MESSAGE-----
[email protected] - my voice is my passphrase authenticate me
-----BEGIN SIGNATURE-----
18neTpQ5MWnXg4n4rpoK5TgxXjEVcg2MYR
G0d6BnQem1gT4nd9esfsEyn1k/GfYAxDkNJmkNvmz8wCOI2Ncw9DvIcyP7OJcEvWbUHQNIBFK3V8wYdnhEFhYHI=
-----END BITCOIN SIGNED MESSAGE-----

The core differences with this format (as specified in this thread and the PGP rule-set are:

  • No “empty-line” delineator between the headers and message;
  • Beginning and end whitespace / newlines ignored excluded when verifying the signature;
  • Length of rows are not limited to 80 characters;
  • No concept of header values (like versions).

The reason I point this out is that since there really isn’t a standard for this signature format and the format diverges from what has been used historically you may still encounter interoperability issues when validating messages between clients that have not been tested with each other.

With that said when you have managed to successfully verify a message like this you know that whoever produced the message owns the key associated with the wallet associated with it.

To address the risk of a message substitution the sender would need to communicate a challenge out of band to the recipient. For example you may notice in my message above I included “my voice is my passphrase authenticate me”. My inclusion of this message (presumably exchanged out of band) helps assure the sender that it was me who signed the message.

To make this process a little easier Andrew Yanovsky and I put together a simple site that can validate both formats, it’s all client side so you can save the files locally and run without the dependency on the website if you like.

NOTE: It is worth noting that this workflow does not accommodate P2SH and multi-signature wallets both of which will see increased use as time progresses.

Do a micro-transaction

The simplest way to verify an address is to simply send a small amount of money to that address and verify out of band with the recipient that they confirm seeing it in their balance. This is what most online payment services but again this requires the keys to be accessible to the sender they can perform the transaction.

There are a few things to keep in mind if you go this way, specifically:

  1. Don’t send less that .0001 BTC because the transaction may get “stuck” and not be processed.
  2. Be sure to include some transaction fee even if tiny so it doesn’t stay unprocessed for too long.

Once the transaction has been sent and you use a tool like blockchain.info to see that the transaction has been confirmed you can verify out of band with the address owner again that they see the funds as well.

This approach unlike the wallet signing key approach can also work with multi-signature and P2SH wallets which will be in use increasingly as clients better support these techniques.

Verify the wallet address two times via out of band channel

If they keys are offline (in cold storage) the only viable option is to carefully validate each character of the address via an out of bound secure channel, I would personally not rely on this approach for large sums but if both parties are careful it can work. By doing the check twice you reduce the chance of human error but mistakes can happen and in this case they can not be undone so use this approach with caution.

None of these solutions are perfect and moving forward I expect we will see services like OneName.io and exchanges with authenticated account profiles will become the way that we solve these problems but in the mean time you can reasonably manage the transaction workflow via these two mechanism.

The bias of experience and ignorance of youth

Leave a reply

It was really security (well pirate and BBS’s and IRC channels) that first got me seriously into computers. It was a place where I was surrounded with brilliant people and super interesting problems to explore. It did not take long for me to discover cryptography. I remember the first time I encountered the concepts; I was working on cracking a game and the publisher actually had encrypted some of the instructions and I had to figure out what it was they had used, how it worked and how to work around it.

At that moment I was hooked. Since then nearly every professional experience I have had has been in computer security — simply put I love this stuff.

As it turns out most of the last two decades I have ended up working on authentication systems of one sort of another; these end up being interesting applications of protocol design, performance design patterns and cryptography.

The nature of these spaces also resulted in me working on operating systems and security services which in turn led me to have a strong bias against the “web developers” who I viewed largely as script kiddies with no understanding of computer science fundamentals let alone security. So much so I discouraged my son from learning many of the associated technologies because “real programmers” don’t bother with such things.

There has been an amazing shift over the last decade and even if at one point I was right for the above position I certainly would not be today. Not only have the technologies that are used to make up the web evolved to the point that they are as impressive and powerful as many of their native counterparts but many of the engineers working with them have become world-class as well.

This has led to some interesting trends the most poignant being the adoption of Javascript as a language for use outside of the browser like in Node.JS and the Tessel. This has been enabled by a competitive race to build the fastest experience on the web, which has become totally dependent on Javascript.

As a technologist I love this as it makes technology more approachable, it makes it easier for things to be rapidly be built and creates portability of skill across the layers of an engineering project.

As a security practitioner it gives me pause; those of you who know me one of my favorite sayings is “Just because you can, doesn’t mean you should” and since this approachability and increased speed of innovation has obvious and natural negative implications when securing systems I am hesitant still to embrace it fully.

I take solace in this dichotomy because of something my mom would always tell me – You’re not learning if your not falling.

As we look at the features in HTML 5 and their support of things like WebCrypto, WebSockets and (god forbid) WebGL I try to remind myself how important it is not to let our personal biases hold back innovation while holding onto the rational and caution approach of my inner security practitioner.

Bitcoin Paper Wallets and Digital Backups

Leave a reply

The folks working on Armory have done a wonderful job thinking about many of the risks associated with Bitcoin and Paper Wallets. The have even gone as far to consider the risks of a compromised printer with a feature they call SecurePrint™.

In the Certificate Authority world when managing secrets that can not be kept within a Hardware Security Module (HSM) we go a further by using similar key management tools on Tempest hardware physically located in Faraday cage under rigorous ceremonies designed to ensure every single step performed is confidential, verified and audited.

For the individual moderate Bitcoin holdings Armory provides a robust story for managing wallet keys and producing paper wallets especially when paired with something like the PiWallet. That said since once doesn’t need to physically take your Bitcoin (they can just take a copy of it) make it their own how you store it is also important.

For valuable secrets that must be stored on paper a Certificate Authority would fold the corresponding paper in half taping each of the open ends close using tamper evident seals.

They would then place each sealed paper into their own opaque tamper evident bags keeping inventory of the bag and seal serial numbers, who was present and then storing the bags and inventory in separate secure locations.

This not only makes it possible to detect what has happened with the stored paper but protects it from water as well. Consideration is also given to what kind of paper and toner is used; for most scenarios one would use archival quality paper and high quality toner. But paper burns and toners are made of organics that can break down in heat so electronic copies are often also kept.

When it comes to those electronic records the choice of what media you use to store those values is important, as many types of media are not reliable for long-term storage. Today I would use the MDISC which effectively engraves the data into a disc that is still readable by modern DVD and BluRay players promising the disc to be readable for 1,000 years.

Even though most data being stored would already be cipher-text one never wants to rely on a single point of failure and for this reason another layer of crypto would typically be used. Commonly this is as simple as using GPG or TrueCrypt with a password to encrypt the data you are going to write to the disc in-turn managing the security of that password carefully.

At this point your down to being concerned with the physical protections your storage facilities offer and ensuring you have long term access to the hardware and software necessary to use the artifacts captured above.

Keeping long-term passwords secured

Leave a reply

We all know that passwords should be changed regularly to reduce the value to an attacker and that they should be stored in ways that they can not be easily compromised which is why generally people are encouraged not to write passwords down.

The reality is that the human brain can only retain so much information and the less often you use something the more likely it is that you will forget it.

This is true regardless of how memorable your password happens to be.

This is especially true for passwords used in key management ceremonies. Imagine being there when the first keys were generated for the first root CA on the Internet, this is a key that will exist for decades and the implications for loosing access to this key are huge. More over the passwords involved in these ceremonies do not bellong to an individual, they belong to an organization.

For these reasons key management ceremonies use password record forms; I have attached an example form to this post for your reference.

These forms once filled out are stored securely, how securely being dependent on the security needs of the scenario. For example if the password was associated with a share in a Shamir Secret Sharing scheme (M of N set of keys) one would transport and store them securely in facilities geographically distributed under lock and an dual lock control scheme.

Periodically these stored values are retrieved and changed, as part of a process to ensure continued access to systems and keys is possible.

While not something the average person needs to deal with it is relevant to those doing paper key management for large amounts of Bitcoin, important DNSSEC keys or maybe keys embedded into some device that has been mass produced.

Protecting Bitcoin keys with hardware

Leave a reply

One of the most important things you can do to keep your Bitcoin keys safe is to get them off of your general-purpose computer and onto a single use device that is designed to perform cryptography or Bitcoin operations.

This protects you from a number of different attacks that could result in the compromise of your keys but it does so at an expense — it makes it more difficult for you to spend your Bitcoin.

This is of course not unique to Bitcoin; in the Certificate Authority world we think of utility keys (e.g. OCSP and Time-stamping) differently than we think of the keys associated with issuing certificate authorities (the ones used to sign subscriber certificates) which we think of differently than keys associated with root certificate authorities. As such we apply different key management techniques and policies to each of them.

The same is true for your bank accounts; you keep less cash in your checking account than you do your savings. This is in part because you have a bankcard and checks tied to the checking account which makes it easier for an attacker to access your funds.

If you manage your Bitcoin holdings in a similar way by having wallets for your “spending money” and wallets for your “savings” then you make it possible to apply security measures that balance convenience and security while managing your risk. These are commonly referred to as “hot” and “cold” wallets.

Additionally those people with large cash assets limit how much they keep in each account so they stay within the liability limits that their financial institutions offer (for example $250,000 USD in the case of FDIC insured institutions).

Traditional banks do the same sort of things; for example a bank with $80,000,000 USD is required to keep $8,000,000 liquid they then use the remainder in fractional reserve banking as a working asset to fund the bank. This also has the side effect of distributing the risk the bank is exposed to by distributing that capital into many different investments each with their own risk profiles.

So how does this all translate to Bitcoin and hardware key management? For most online wallets such as Coinbase are a fine way to manage the funds you spend regularly but for your savings its advantageous to manage these keys yourself instead of being part of a much larger target like an online wallet.

That takes us to Bitcoin key management solutions; Since its introduction there have been many proposed solutions. Most of these being based on either specially hardened and dedicated computers using LiveCDs like this one built on Ubuntu and this one in Tails, these images use wallets like Armory and Electrum to in these clean-room environments to perform Bitcoin operations.

The processes used here are logically equivalent to what Certificate Authorities do with “ceremony computers” where they use specially prepared Tempest rated computers in Faraday Cages with no visibility from the outside that have isolated power (protecting against Differential Power Analysis) to generate and perform operations with sensitive keys.

During these ceremonies ridged processes and controls are used to configure the machines using known software verifying every binary is as its expected to be, auditing every action under camera with multiple people auditing the activities taking place. Also when keys are generated they are protected using secret sharing schemes such as Shamir Secret Sharing and the shares are distributed to different parties who then travel separately and move those shares to secure storage facilities that are geographically distributed.

Obviously there are lots of dials you can “tweak” to control the time / complexity tradeoff involved in the above process but for those with moderate Bitcoin holdings the above would broadly be considered too onerous to even consider.

This is where turnkey products come into play while there have been a number of promising proposals producing something that is secure, usable and affordable is no small task and most of these projects have failed to achieve sufficient market penetration to succeed.

At this time the most promising solutions that are (to varying degrees available) are PiperWallet which is an Open Source printer with embedded RasberryPi that can be used to create paper wallets, based on its claims it has thought about all the right problems (quality of random numbers, etc.)

Another solution is the Open Source PiWallet, this isn’t terribly different than the PiperWallet conceptually (through it does not make any claims about the quality of its random numbers) but it doesn’t include any input or display without an added display and keyboard.

One of the most promising offerings in this space is the Trezor this is a custom designed device designed not only to be useful for cold wallet storage but for actual personal hot wallet use as well. I am looking forward to getting a chance to use one once it becomes generally available.

On the high end of the equation one could also use a Thales nCipher or a SafeNet while these devices are not Bitcoin specific they can be used along with a ceremony computer and a modified Bitcoin wallet to secure the keys used in your wallets.

Above and beyond these solutions there are a half a dozen half-done not maintained smart card solutions (1 ,2 , 3) that have potential but unless you’re a JavaCard developer and/or Smart Card Professional these are frankly not viable options yet.

 

Keeping an eye on your Bitcoin keys

Leave a reply

In the government, banking and certificate authority worlds important keys are generated and used within specialized cryptographic devices called Hardware Security Modules (HSMs) or their less powerful cousins smart cards.

In the Bitcoin world keys are most commonly generated and stored in software running on the same machines people use for surfing the web. This means those keys are exposed to all of the same risks as the rest of your computing experience.

This is why there are now multiple variants (1, 2, 3) of wallet stealing malware and many cases of Bitcoins being stolen through key compromise (1).

The reality is we have not even touch the tip of the ice-burg on the sorts of attacks that expose these software keys and as Bitcoin becomes more mainstream the techniques used by attackers will improve so that they can overcome the mitigations more advance software is surely to use.

For example a lot of effort was spent mitigating in memory key access threats in Windows by moving keys out of process and working to minimize the amount of time the key was left in its unencrypted form. In-fact the inadequate in-memory protection of keys in OpenSSL was a contributor to the recent #Heartbleed vulnerability.

It is not possible to totally mitigate the risk of in-memory keys but you can reduce the exposure. Even when you do there will still be moments when they or the components that were used to make them may be exposed; For example they may simply get dumped into your page file

So what can you do to protect yourself? The most important mitigation available to you is to do what governments; banks and certificate authorities have been doing for decades – generate and use your keys within specialized devices. The bad news is that even though there are many projects that aspire to help you do just that for Bitcoin your choices are still quite limited – especially if you want ease-of-use and accessibility.

Absent reasonable hardware solutions for key management people often resort to storing their Bitcoins on paper using keys generated on hardened dedicated operating system installs not connected to any network and while this is an useful technique in your arsenal even paper keys can be compromised through carelessness.

In military and aerospace systems things are often designed for triple redundancy and if your storing a large amount of bitcoin you should also keep this principal in mind when designing your key management strategy.

Not doing so sets you up for failure, just look at Mt. Gox. If we believe Mr Karpele’s story he did not know how much Bitcoin he had at any one point and according to reports he also set himself up as a single point of failure.

Though the advent of multi-signature wallets in Bitcoin along with third-party services like BitRated will help people manage this sort of risk in the future it does not mitigate the need for solid accounting and monitoring of your balances.

As such it also makes sense use wallet watcher services such as Blockchain.info’s “Watch Only Addresses” or BTCBalance.net so that you can know what transactions are happening with your keys at any point and time.

If you have a large amount of Bitcoin it also makes sense to use a Honey Pot where you have wallet(s) placed in locations where they are easily accessible and monitored via services like the above so that you know you need to respond accordingly.

In short when thinking about your key management strategy it’s a good idea to keep in mind what Benjamin Franklin said: By failing to prepare, you are preparing to fail.

Insurance and Bitcoin

Leave a reply

There are lots of ways we risk loosing our money one of the biggest is when the institutions we trust to keep those funds safe fail to do so.

This happened in the United States during the Great Depression when widespread bank failures destroyed lifetimes of savings overnight.

To address concerns of this happening again the FDIC and NCUA were created in the 1930s to provide assurances that if such an event were to happen again their savings would still be safe and even this has its limits.

This along with regulations that were put into place around minimum liquidity and other practices are what helped people begin to regain trust in the US financial system.

The fall of Mt. Gox and other smaller exchanges has once again introduced similar concerns but thankfully the influx of venture capital to the Bitcoin ecosystem has brought in a new class of organizations who have both the skill and capital to run more professional institutions.

As a result we now are seeing vault services starting to offer similar insurance via self-insurance programs coordinated with underwriters such as Lloyds of London and Meridian.

This is a huge step forward but there is a long way to go before these offerings are viable because as they stand today its far from cost-effective. As an example lets look at Elliptic if we were to store $250,000 USD of Bitcoin (510.58 BTC at todays price) you would be paying $5,064 USD every year for that peace of mind.

That’s not to suggest everyone needs $250,000 of insurance or that this is not a “reasonable” fee for this service but the reality is the price for this assurance has been established and its FREE.

Vaulting services such as Elliptic and Xapo are also a little different than traditional banks because they do not (for the most part) offer other services. Additionally building and operating services that provide the necessary assurances to qualify for such insurance comes at a cost above and beyond the cost of the insurance itself so a premium of some sort must be charged. The costs here are sure to go down as they get amortized across more customers but regardless the current cost structure these services are based on are out of reach of mainstream users.

Making this insurance more accessible will be necessary for us to see this broader adoption of Bitcoin along with many other changes that will include regulations (either self enforced like the NCUA or government mandated). This will include things like reporting requirements, minimum liquidity levels, operational practices, key management requirements and insurance.

When it comes to insurance I think we will also see it become a “freebee” just like in the classical financial institutions where its costs are built into the profit model of the institution. Today classical financial institutions cover these costs via account maintenance fees, transaction fees, the profit they make on the money they hold for others (via fractional reserve banking) and the overall revenue diversity in their business models.

In the meantime the insurance these vaulting services offer fill a market need for those with large amounts of Bitcoin and but not the time or skill to protect the keys themselves.

The irony is of course it’s the little guy who likely needs the insurance more.

What’s in a certificate chain and why?

1 Reply

Have you ever wondered why your web server certificate has a “chain” of other certificates associated with it?

The main reason is so that browsers can tell if your certificate was issued by a CA that has been verified to meet the security, policy and operational practices that all CAs are mandated to meet. That certificate at the top of the chain is commonly called the “root”. Its signature on a certificate below it indicates that the CA operating the root believes that practices of the CA below it meets that same high bar.

But why not issue directly off of the “root” certificates? There are a few reasons; the main one is to prevent key compromise. To get a better understanding, it’s useful to know that the private keys associated with the “root” are kept in an offline cryptographic appliance located in a safe, which is located in a vault in a physically secured facility.
These keys are only periodically brought out to ensure the associated cryptographic appliance is still functioning, to issue any associated operational certificates (for example an OCSP responder certificate) that may be needed, and to sign fresh Certificate Revocation Lists (CRLs). This means that for an attacker to gain access to these keys, they would need to gain physical access to this cryptographic appliance as well as the cryptographic tokens and corresponding secrets that are used to authenticate the device.

CAs do this because keeping keys offline is a great way to reduce the risk of a compromised key, but it’s a poor way to offer a highly available and performant service, so the concept of an Issuing CA (ICA) was introduced. This concept also enabled the “root” to respond to CA key compromise events by revoking a CA certificate that should no longer be trusted. This also enables delegation of control, limiting those who can influence a given ICA to sign something.

Another way CAs solve the “online CA” problem is to use what is commonly referred to as a Policy Certificate Authority (PCA). This model allows a CA to segment operational practices more granularly. For example, maybe the CA is audited to be in compliance with a specific set of government standards so the ICAs associated with those practices would be signed by the corresponding PCA. This not only allows segmentation of policy and procedures, but it also enables separation of usage scenarios. For example, one PCA may only allow issuance of certificates for secure mail while the other PCA may allow issuance of SSL certificates. These PCAs are also very commonly operated as offline entities and have ICAs right underneath them.

While the above two models represent the most common ways a PKI might be segmented, they are not the only two. For example, the operational practices required to be a publicly trusted CA are far stricter than what a typical data center might employ. For this reason, it’s very common for CAs to manage PKIs for other organizations within their facilities.

CAs may also “roll” ICAs as a means to manage CRL size. For example, if a given CA has had to revoke many certificates during its lifespan, it may decide to manage the size of CRLs – it would be appropriate to create a new ICA and take the previous one out of service so that future CRLs can still be downloaded quickly by clients. When this happens both CA certificates may be valid for an overlapping time, but only the more recent one is actively in use.

Long story short, some counts on the number of Certificate Authorities that exist on the internet can be deceiving. One of the easiest ways to see this is to look at a CA called DFN-Verein. They are an educational PKI that manages all of the CAs in their PKI in the same facilities, using the same practices, but for security reasons they create separate ICAs for each organization in their network.

Simply put, the count of CAs in a PKI is not a good way to assess the number of entities issuing certificates in the PKI ecosystem. What you really want to count is how many facilities manage publicly trusted certificates. The problem is that it is too difficult to count – what you can do, however, is count the number of organizations associated with ownership of each “root”. Thankfully Microsoft makes this fairly easy. In March, I did a post on my blog showing a breakdown of the ownership. Unfortunately, this approach does not give you a count of operational facilities that are used for the subordinate CAs, but it’s quite likely that given the operational requirements and costs associated with maintaining them that these two numbers are relatively close.

So what would I like for you to take away from this post? I suppose there are two key points:

  • A public CA using several Certificate Authorities under their direct control is actually a good thing as it indicates they are managing the risk of operating their services and planning for migrations to new algorithms and keys as appropriate.
  • Counting the number of “roots” and “subordinate CAs” found by crawling the web does not actually represent the number of organizations that can act as publicly trusted certificate authorities.

That is not to say the efforts to crawl the web to understand how PKI is deployed and used is not valuable, it is – quite valuable. These projects are an important way to keep an eye on the practices that are actually used in the management of Public PKI.

Additionally, efforts to support Least Privilege designs in PKI and adopt means to actively monitor certificate issuance, such as Certificate Transparency, all represent positive moves to help us better understand what is actually out there.

How to generate and send a timestamp request for Authenticode

Leave a reply

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.