Digital Signatures: What They Are, How Do They Work and What Is It Like Using Them?

12 07 2012

Have you ever received an email from someone that described a topic so important to you that you really wanted to make sure that the person you thought sent the email actually did and that the message was exactly what they had written?  Or have you ever accidently sent an email to someone that you didn’t mean to send and then you denied sending it?

Let’s consider the first case.   Let us say that you arrive at work one morning, turn on your computer and login to your email system.  You receive an email from your boss that simply states, “Good morning.  You are fired.  Please go home.  Thanks, Andy Smith”.

Now, what do you do?  Do you simply look at the address line and see the senders address (Andy Smith) and pack your bags?  Or perhaps you are a little suspicious, so you at least check the senders full email address in the message properties (asmith@company.com).  So, after this checks out, do you go home?

This example involving being fired via email actually describes a scenario where digital signatures could be used to great advantage.

What is a digital signature?  Peter Gregory defines a digital signature as a “method used to verify the authenticity and integrity of a message or document”. [i]

From this definition it is clear that digital signatures actually serve two purposes, much like documents signed with a pen.  A personal signature placed on a document via a pen is relatively unique.  We could certainly study the strokes of the pen and most signers would be able to recognize whether they signed a document or whether the signature was a forgery.  Most paper contracts contain signature blocks on each page to verify that the text of the page was also agreed to by signature.  However, the true integrity of a message is difficult to enforce in a pen signed message.  In today’s age of high resolutions scanners and printers, copying signatures and transferring them to other documents or changing text graphically is all too easy.  So, the integrity of a pen-signed document can be questioned.

In the digital document domain, however, digital signatures are used to enforce non-repudiation.  What is this?  Non-repudiate is the opposite of repudiate. Dictionary.com defines repudiate as “to reject with denial[ii]  Therefore, non-repudiate in the digital signature realm means that you cannot “reject or deny” having personally sent a message.
But, we can’t stop there.  A digital signature indicating that a message came from your boss is useful, but how do you know that the message was not altered after it was sent?  This is the second purpose of digital signatures, as they are used to enforce message integrity.   It is important to know that the original message that our boss sent was not “Good morning.  You have been doing a great job.  Why don’t you take the day off!  Please go home.  Thanks, Andy Smith”.

The message giving you the day off is completely different than the message indicating that you are permanently off (fired).

So, when you receive that message from your boss indicating that you are fired, the purpose of a digital signature is to guarantee that your boss actually sent the message and that the message you received is in fact the message that he/she sent.

But, how does this work?

Figure 1 and the accompanying description provided by IBM outlines the digital signature process as it applies to a signed message:

Figure 1. The digital signature process

“The steps of the digital signature process are as follows:

  1. The sender computes a message digest and then encrypts the digest using the sender’s private key, forming the digital signature.
  2. The sender transmits the digital signature with the message.
  3. The receiver decrypts the digital signature using the sender’s public key, regenerating the sender’s message digest.
  4. The receiver computes a message digest from the message data received and verifies that the two digests are the same.” [i]

As you can see, the digital signature process actually involves concepts from Public-Key Infrastructure (PKI) and they are actually constructed of two pieces, a message digest (or hash) that has been encrypted using the sender’s key, and the actual message.  The encryption of the hash by the sender, once successfully decrypted using the sender’s public key, guarantees that the message came from the sender.  The message hash computed at the receiver side can then be compared to the decrypted hash.  If they match, then we have satisfied the second goal of a digital signature, “verified the signed messages’ integrity”.

So, digital signatures are useful, and they are implemented using some complex encryption techniques, but how do they work in “real life”?

I took an opportunity to create a personal digital signature and I learned of a few limitations that you should be aware of.

First, I found a Digital ID service, so that I could buy a personal certificate to use as my signing certificate.  I chose VeriSign™.   The steps involved in buying the certificate were as follows:

1)  I entered the site and began the VeriSign Class 1 Digital IDsm ordering process.

2)  After paying the $19.95, I received an email at my registration email address indicating a digital PIN that needed to be entered into the VeriSign Digital ID Service page to generate a certificate.

 

3) After a few seconds, my certificate was created and automatically downloaded into my browser.

4)  From there, I just saved the certificate by using a password to encrypt the certificate on my machine.

5)  I uploaded the certificate to Microsoft™ Outlook using the procedure found at: http://www.itechtalk.com/thread9912.html [i]

After completing this process, I immediately changed my email client to add a digital signature to all of my emails.  This seemed to work well for other users within my organization, as a digital signature icon appeared at the top of my messages that had been signed.

However, the first messages I sent outside of my organization uncovered some issues.  I sent an email to one user and they replied from their smartphone that I had sent them a blank message? I tried again, same result.

I was upset.  Why was this happening?  I turned off the digital signatures and resent the email.  The result was successful and the message text was received.  I was perplexed.  I immediately realized that the use of digital signatures was not seamless and trouble-free, despite what I had anticipated.  Why?

It took a few minutes and some testing to see what was going on.   I sent a test email to my personal account using Gmail and immediately saw the problem.  My message was not blank, but it only contained my company’s confidential legal disclaimer that was added to all outbound messages.  I looked more closely and the message had an attachment.  What was this?

The attachment was called smime.p7m?  I opened the attachment and there was my message contained after a header that started as follows:

MIME-Version: 1.0

Content-Type: multipart/signed;

            protocol=”application/x-pkcs7-signature”;

So, now I knew what was going on.  A quick check against the S/MIME 3.2 Message specification[ii] showed that this was in fact a MIME header that any modern mail program could read and properly format.  By why did I have two emails?  I had only sent one email.  Or did I?

Remember, our definition of the digital signature involved authentication and integrity.  My message had been altered after sending the message because the company email server had added the legal confidentiality disclaimer.  Given my message had been hashed and encrypted to go along with the email to be used by the recipient for an integrity check, had the email server simply added this disclaimer text to my email, the hash computed by the recipient would not match the hash computed by my email client at the time the message was sent. This would have immediately cast into doubt the integrity of my message and the recipient would no longer be able to trust my message.

To prevent this, the email server just created a new unsigned message and placed the disclaimer text within that message.  The original signed message was sent as an attachment to the legal disclaimer message.  Thus, my signed message integrity was maintained.   On a smartphone, however, the message will appear blank (or will show a disclaimer if the sending email server adds this to all messages), and the original message will be included as an attachment.  This could confuse a recipient, so keep this in mind.

Hopefully, this has given you some practical, technical and real world information about digital signatures and their use.

Oh, yes, and before I close, what about that second case that I mentioned at the beginning?  Well, if you have ever sent an email that you didn’t mean to send and then you tried to deny sending it, if you used a digital signature on your message you’re out of luck!   You had better have a good excuse because the recipient knows it was you!


[i] CISSP Guide to Security Essentials, © 2010 Course Technology, Cengage Learning, p. 179-180.

[ii] Dictionary.com Unabridged, Based on the Random House Dictionary, © Random House, Inc. 2012.

[iii] IBM WebSphere MQ Version 6.0, Cryptographic concepts, Digital Signatures, Copyright IBM Corporation 1999. <http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzas.doc/sy10520a.gif&gt;

[iv] ITtechtalk.com, Add a Digital Signature to the outgoing E-mail Messages





Importance of SSL certificates – implication from DigiNotar issue –

18 09 2011

Many companies’ website have SSL certificate issued by trusted Certificate Authorities (CA) to prove that the connection between a website and a user’s browser is secure. It helps them not to be stolen private information such as health history and credit card numbers.

So what happens if a trusted Certificate Authorities issues fraudulent certificates? You can’t distinguish whether the website you are visiting is fishing site or not. Even if you are encrypting your transaction, someone might be able to steal your user ID and password.

And it HAPPNED on Aug 29th. The news said [1], “An Iranian user reported that there is the threat of man-in-the-middle attacks using a fake SSL certificate that was circulating as of Aug. 29. The fake certificate, which was legitimately signed, was displayed when logging into Google’s Gmail.”

This SSL certificate was issued by a Dutch CA called DigiNotar. They had an illegal access to their site on July 19th and issued more than 500 fraudulent certificates for major domains such as google.com, skype.com, http://www.facebook.com, *.windowsupdate.com, and the Dutch government official websites.

Most of the browser vendors reacted immediately to distribute the updates to ignore the SSL certificates issued by DigiNotar. However, there may be some people whose private information was stolen during July 19th and Aug 29th.

This year, we’ve seen a lot of news related to security issues started from Sony’s case [2]. It’s hard to protect ourselves if the Hackers hack the companies which we believe. However, I think we can do at least two things to mitigate the risks. One is that keep updating the latest version of updates for each software. And the other is that try to understand the basic technical aspect of the issues. In DigiNotar case, without understanding of SSL certificate, we don’t know how much impact it may have.

[1] http://www.eweek.com/c/a/Security/Fake-Google-SSL-Certificate-Emerges-With-Ability-to-Hijack-User-Accounts-270126/

[2] http://ctoinsights.trendmicro.com/2011/06/what-we-can-learn-from-recent-hacks/





How many Certificate Authorities do you trust?

31 08 2011

*disclaimer*  This isn’t meant to be a shining example of a good blog post, so don’t take it as such. It’s me throwing this up quickly because I want you all to go read about this issue.  */disclaimer*

Go ahead, I dare you. Open up your certificate stores in the browser you’re using and tell me with confidence that you know what all those certificates are and exactly where they came from. Therin lies a problem. Users blindly trust that when the little lock icon appears, they’re safe and would have no real idea if a Man in the Middle (MiTM) was compromising a supposedly secure connection between them and – anything (e.g., bank, Gmail, Yahoo, etc…).

This week, it was published that DigiNotar was hacked and bad SSL certificates were released to users who may have been subject to attack. Read more here and here.

There are a number of ways to deal with this problem (DNSSEC for one), if you approach it from a “how to fix the entire infrastructure” perspective. That’s daunting and unlikely to be very effective in the near term. You could also just worry about yourself so that you aren’t a victim – hey, we’re all looking out for number one, right? To do that, go download Perspectives, an extension for Firefox developed here at CMU. The short version is that they use notary servers to query well-known sites to validate the SSL certificates that they’re using. They poll them regularly and can tell you how long a particular certificate has been used and it will warn you, if you set the preferences to do so, that it suspects something may be amiss. You should read the long version on their site for yourself.

*UPDATE*  I was clued in to the fact that another tool was recently built and briefed by a well-known researcher named Moxie Marlinspike.  I believe he has used Perspectives as an early model, though I’ve not confirmed this for myself.  So, perhaps you want to use his tool instead, though it’s in beta and may not support Firefox v6.  Link here.

Who can’t wait to get to week 4 when we start crypto?

Adam