Category Archives: Certificates

SSL Exploration and Analysis

During the recent investigation of certificates and SSL, a co-worker (Ola) forwarded a web link about an organization that is analyzing web SSL certificates.  The information was very relevant and interesting.

The EFF SSL Observatory


Quote from site:

The EFF SSL Observatory is a project to investigate the certificates used to secure all of the sites encrypted with HTTPS on the Web. We have downloaded a dataset of all of the publicly-visible SSL certificates, and will be making that data available to the research community in the near future.

 

The best way to get started is by looking at the slide deck.  The overall summary indicates that things need to tighten up quite a bit to provide a more secure environment.  It is too easy to make mistakes and open security holes.  The philosophy of exposure reminds me of the work done by W. Richard Stevens for TCP/IP many years ago.  The more an item is explored, the more likely its vulnerabilities and flaws will be seen.

This post resulted from cleaning up the inbox and realizing that this information was valuable enough to share.

Public Key Certificate Locations in Windows

Since last week I have been looking more at depth with how certificates work.  One thing that was bugging me was not knowing where the information is stored.  There are plenty of references to the certificates being stored in files and the registry but no actual paths.

On late Friday there was a bit of a breakthrough.  Somehow I managed to identify a location in the registry that contained a certificate (this was using regedit and doing a search on ‘cert’ if I remember right).

This subkey tree is located at HKCU\Software\Microsoft\SystemCertificates.

These certificates are considered to be CurrentUser whereas the shared ones are in LocalMachine.  Searching for SystemCertificates found an excellent reference from a Microsoft web page.  It is a bit old, but contains valuable information.

CA certificate-related registry entries correlate to the physical view of the certificate-related data that can be viewed by using the Certificates snap-in.

The registry settings in this section are a subset of the registry settings in “Certificate Services Tools and Settings.” This subset makes it possible to monitor and manage key configuration options associated with CA certificates.

The following registry keys are associated with CA certificates that were distributed via Group Policy:

  • HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates
  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates

The following registry keys are associated with CA certificates that were not distributed via Group Policy:

  • HKEY_CURRENT_USER\Software\Policies\Microsoft\SystemCertificates
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

This summary shows where the certificates live for the different combinations. The keys are encoded as “blob” values under GUID identifier key names. It appears that the blob is just a binary representation of the certificate.

Each subkey off of the SystemCertificates above shows up in Certificate Manager (certmgr.exe) under a slightly different name.

The mapping is not necessarily easy to work out.  Hopefully in a future post it will happen.  The most important ones to note are “my” and “root”.  “My” is “Personal” and “root” is “Trusted Root Certificate Authorities”.  My current theory is that these folders can be a bit free form HOWEVER they do have a purpose and essentially control access to specific features.  For example, “root” is used extensively to guarantee that the root CA is trusted.  If the certificate lives in this folder, essentially all Windows cert operations (think SSL) will trust any certificated signed by this root CA.

Let’s take a look at certificate using normal tools and using the registry editor.

This is a test certificate that was built to try some Azure samples.  Note that it has a private key.  The certificate lives under “Personal” on “CurrentUser”.  This translates to HKCU with “My”.

Here is a bit more detail from certmgr:

Hopefully this will make some sense against the registry entry.  And, it does not.

This is where I admit that not everything as it seems.  It turns out the majority of the interesting certificates are actually on the disk.  The Personal certificates were found in “%UserProfile%\AppData\Roaming\Microsoft\SystemCertificates\My\Certificates”.  How’s that for assuming the wrong place?

The directory and files (certificates) are hidden so you will have to play with ATTRIB or Windows Explorer options to get to them.  It looks like this:

This corresponds to the seven certificates seen in certmgr (MMC with snap-on certificate handler).  I just noticed that these names correspond to the thumbprint of the certificate (SHA1 : 16 bytes).  This should make it easier to find the certificate that we started with (test.cloudapp.net).

It matches one of the file names:

To get a better look at this file, I used attrib to strip off the system flag (attrib -s) and copied (copy /b) it to another directory.  Then I used my hexdump tool to display what it had inside.

Test Certificate binary content

Clearly this is the right one.  The chances of having the wrong filename based on SHA1 is almost impossible.

The next post will focus on the location of the private keys.

Certificate Public Key Usage

Public keys that reside inside certificates are only meant to be used for certain things.  This is indicated by the Key Usage and Extended Key Usage extensions.

The first stop is documentation from OpenSSL.

Key usage supported names:

  • digitalSignature
  • nonRepudiation
  • keyEncipherment
  • dataEncipherment
  • keyAgreement
  • keyCertSign
  • cRLSign
  • encipherOnly
  • decipherOnly

Extended Key Usage names:

Value                  Meaning
 -----                  -------
 serverAuth             SSL/TLS Web Server Authentication.
 clientAuth             SSL/TLS Web Client Authentication.
 codeSigning            Code signing.
 emailProtection        E-mail Protection (S/MIME).
 timeStamping           Trusted Timestamping
 msCodeInd              Microsoft Individual Code Signing (authenticode)
 msCodeCom              Microsoft Commercial Code Signing (authenticode)
 msCTLSign              Microsoft Trust List Signing
 msSGC                  Microsoft Server Gated Crypto
 msEFS                  Microsoft Encrypted File System
 nsSGC                  Netscape Server Gated Crypto

Now, moving on to a more detailed source from IETF (RFC 3280):

4.2.1.3  Key Usage

   The key usage extension defines the purpose (e.g., encipherment,
   signature, certificate signing) of the key contained in the
   certificate.  The usage restriction might be employed when a key that
   could be used for more than one operation is to be restricted.  For
   example, when an RSA key should be used only to verify signatures on
   objects other than public key certificates and CRLs, the
   digitalSignature and/or nonRepudiation bits would be asserted.
   Likewise, when an RSA key should be used only for key management, the
   keyEncipherment bit would be asserted.

   This extension MUST appear in certificates that contain public keys
   that are used to validate digital signatures on other public key
   certificates or CRLs.  When this extension appears, it SHOULD be
   marked critical.

      id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

      KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1),
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

   Bits in the KeyUsage type are used as follows:

      The digitalSignature bit is asserted when the subject public key
      is used with a digital signature mechanism to support security
      services other than certificate signing (bit 5), or CRL signing
      (bit 6).  Digital signature mechanisms are often used for entity
      authentication and data origin authentication with integrity.

      The nonRepudiation bit is asserted when the subject public key is
      used to verify digital signatures used to provide a non-
      repudiation service which protects against the signing entity
      falsely denying some action, excluding certificate or CRL signing.
      In the case of later conflict, a reliable third party may
      determine the authenticity of the signed data.

      Further distinctions between the digitalSignature and
      nonRepudiation bits may be provided in specific certificate
      policies.

      The keyEncipherment bit is asserted when the subject public key is
      used for key transport.  For example, when an RSA key is to be
      used for key management, then this bit is set.

      The dataEncipherment bit is asserted when the subject public key
      is used for enciphering user data, other than cryptographic keys.

      The keyAgreement bit is asserted when the subject public key is
      used for key agreement.  For example, when a Diffie-Hellman key is
      to be used for key management, then this bit is set.

      The keyCertSign bit is asserted when the subject public key is
      used for verifying a signature on public key certificates.  If the
      keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension (section 4.2.1.10) MUST also be asserted.

      The cRLSign bit is asserted when the subject public key is used
      for verifying a signature on certificate revocation list (e.g., a
      CRL, delta CRL, or an ARL).  This bit MUST be asserted in
      certificates that are used to verify signatures on CRLs.

      The meaning of the encipherOnly bit is undefined in the absence of
      the keyAgreement bit.  When the encipherOnly bit is asserted and
      the keyAgreement bit is also set, the subject public key may be
      used only for enciphering data while performing key agreement.

      The meaning of the decipherOnly bit is undefined in the absence of
      the keyAgreement bit.  When the decipherOnly bit is asserted and
      the keyAgreement bit is also set, the subject public key may be
      used only for deciphering data while performing key agreement.

   This profile does not restrict the combinations of bits that may be
   set in an instantiation of the keyUsage extension.  However,
   appropriate values for keyUsage extensions for particular algorithms
   are specified in [PKIXALGS].

But wait, the trail goes deeper into “PKIXALGS” which is also known as RFC3279.

If the keyUsage extension is present in an end entity certificate
   which conveys an RSA public key, any combination of the following
   values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyEncipherment; and
      dataEncipherment.

   If the keyUsage extension is present in a CA or CRL issuer
   certificate which conveys an RSA public key, any combination of the
   following values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyEncipherment;
      dataEncipherment;
      keyCertSign; and
      cRLSign.

   However, this specification RECOMMENDS that if keyCertSign or cRLSign
   is present, both keyEncipherment and dataEncipherment SHOULD NOT be
   present.

What does all this mean? There are specific rules about how the usage field controls how the public key is applied. Think of it as a gate to certain activities. A CA certificate has access to more functions than a non-CA (normal) certificate.

Having the usage right to sign another certificate is reserved for CAs. Based on previous posts, this means that you could have a certificate that would never have to right to sign other certificates.

I must admit that it is still a bit confusing how all these combinations fit together. Examples over time will help to clear this up. At least now the different types are clearly identified.

Digital Certificates (part 2 of 2)

Part two continues on the topic of digital certificates.    One of the keys is private and the other is public.

Below are some useful examples and explanations from Novell:

But, how does this work on the Internet for transactions?

Continue reading

Digital Certificates (part 1 of 2)

This post will explore digital certificates.  Consider this as a result of a need to learn more detail about how certificates work.

Start here:

  1. VeriSign: Introduction to Digital Certificates
  2. VeriSign: Introduction to Public Key Cryptography

Paraphrasing:

Cryptography solves many key computer issues (like identification).  Traditional security based on physical devices is useless in the digital world.   In order to protect information and identity, complex algorithms are needed to hide the content and user.

Early generation encryption solved the problem but had a big problem with how far it could transfer its secret keys.  It became too difficult and expensive to safeguard the symmetric keys.  Beyond this, the key trust required new keys for each new trust relationship.  It also implied prior knowledge of the other person.

Since both parties know the secret key, there is no way to know which of the two parties might have modified content or acted as the other.  The shared key does not indicate identification.  Therefore it can not be used to authenticate.

Public key encryption was first created in the mid 1970′s.  For the first time it was possible to transfer secret data without exposing the secret key.   There are two keys (one public and one private) that do the opposite of each other.  If you use the public key to encrypt, only the private key can decrypt.  Likewise, if data is encrypted using the private key, it can only be decrypted by the public key.

The public key is made widely available for all to use.  The private key is only available to the owner.  SSL uses the public keys of servers to encrypt traffic to the web.  The SSL protocol requests the public key from the server directly as part of its negotiation.

If a user wants to send a private message to another person, they use the public key of that person to encrypt the message.  The recipient uses their private key to decrypt the message.

The power of this is that the public key can be used by anyone and the content sent to the private key owner cannot be decrypted by anyone else (assuming that the encryption is strong enough).

Since only one person owns the private key, it is therefore true that if you decrypt data from the users public key, you can be guaranteed that it came from that person.  This introduces the concept of digital signatures.

Sometimes it is only necessary to prove that someone sent data.  The actual data does not necessarily need to be encrypted but the producer and the consumer want to guarantee that nothing has changed and that the content came from the producer.  This is used extensively in code signing.

The quick summary is that a hash algorithm is run against a section of data and the resulting digest (like SHA1) is encrypted using the private key of the producer.  The consumer receives the data and decrypts the digest and compares this against the digest calculated from the received data.  If they do not match, something has been altered that should not have been.

The problem however is that just because a public key is published it does not necessarily mean that the owner is the person you want to trust.  Someone could send you a public key that actually belongs to someone else.  There is a need to guarantee trust.

Digital certificates are the answer.  Similar in nature to a passport or driver license, they uniquely identify you based on a trusted organisation.    The user’s public key is signed by a certificate authority (think VeriSign) that can vouch for you being a valid user/company.  They only sign public keys they trust through a process of proving identity.  Years ago I needed a certificate for Citrix and had to prove to VeriSign that we were who we said we were.  It can be an extensive process based on the level of verification.

Digital certificates contain a number of data items to help verify identity and trust.  This includes the concept of expiration.  Proof of identity only lasts for a specific time (usually a year).

Certificates can be allocated based on a trust hierarchy.  Trust is relative to the parent which can be mapped to many layers before it gets back to a certificate authority root.  Web browsers have a list of certificate authorities they trust and that is the basis of determining trust with HTTPS sites.  Only trusted CAs are allowed.

More in the next post…