14 August 2011

Access Local Machine certificates without Admin rights

Digital certificates in windows, either the end entitty certificates, called Personal Certificates, the subCAs or the Root CAs, are stored in the so called Certificate Stores. There are different types of Certificate Stores but the more relevant ones are:



Personal CA Store: Certificates, either end entities, subCAs or Root CAs, that apply to the current user

Local Machine CA Store: Certificates, either end entities, subCAs or Root CAs, that apply to the system account. These apply to the user too. This means that a certificate issued by a Root CA available in the Local Machine CA Store but missing in the Personal CA Store would be treated as a valid.


In order to have access to the digital certificates used by Windows and integrated applications you need to follow these steps: (Have in mind that Firefox uses its own digital certificate stores).


From the command line open an MMC:

 


In the MMC add the Certificate snap-in




If you have local machine admin rights you have the right to choose the CA Store you want to open, if not it will automatically open the Personal CA Store

 
 
 
The naming can be a bit confusing but you should concentrate in the following folders:

• Personal: These are the end entity certificates assigned to the account (User or System)
• Trusted Root Certification Authorities: The Root CAs
• Intermediate Certificate Authorities: The subCAs

From the Certificate console, you are able to browse, add, delete all different types of certificates. If you need information of the other folders you can check the Microsoft article https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_cmuncertstor.mspx .

 
As said, if the user does not have admin rights he won´t be allowed to choose the “Computer account” where the certificates that apply to the System account are stored. Something that creates a bit of confusion is the fact that the Root CAs and subCAs from that store apply to the current user. Unfortunately these can only be examined by the end user in case his account has local admin machine rights. Although it’s understandable that a restricted user should not be available to apply changes that will affect all users, it makes no sense that it is not allowed to list the complete list of Root CAs available in the System account and that will be trusted in any SSL connection he establishes.

The good news is that the restrictions to access the Local Machine CA Store are rather weak and I just found a quick workaround for this.

From a computer where you have admin rights perform the steps above and repeat them adding the Computer Account. You should have a console with entries to the user and system accounts:

 
 
Go to "File -> Save as" and save the console (with extension msc) in a known directory. Transfer the file using a USB disk or by email to the target computer and you will be able to access the “restricted” Local Machine Store even if the logged user does not have local admin rights.


This is a simple hack but very useful when troubleshooting certificate related problems when users have restricted accounts. I have tested in a Windows 7, if you test it in other platforms let me know the results.

I  just hope that the rest of the Windows 7 access control mechanisms are more robust than this!

04 May 2011

Android default (weak) signing configuration for the developer certificates


Some months ago I created a couple of Android applications.  As every Android developer  knows, in order to deploy applications on Android devices, these need to be signed. In other platforms like IOS, Symbian, Java or Windows Mobile, the signing process is a method used to prove the source of an application. Once an application is signed by a known certification authority, the platform will grant different execution permissions. Android  used code signing slightly different. The developer creates its own self signed certificate and uses this to sign any application he releases. This allows the platforms to recognize updates and also allow secure inter application communication.  The reason is simple, if there was no way to relate an application to its owner it would be trivial to impersonate him or her and deliver fake applications updates.

Without wanting to dig into the controversy between open and closed models, IOS vs Android, the part that caught my attention was that the developer would create a self signed certificate on his own and that that the only requirement is that the certificate must be valid until 2034. Today we all know that MD5 is proven to be weak and that key sizes should be at least 2048b, especially if we need to use it for a few years. On the other hand the default Android tools I used to create the certificate suggested to use a 1024b key and MD5 which is not a good idea, especially if that would be my identification until 2033!!

With that in mind I was curious to see how the digital certificates used to sign Android applications would look like. I analyzed nearly 4.000 applications, extracted the certificates and put together some statistics. For this I used unique certificates, which means that if two applications (in most cases these were updates) were signed with the same certificate I only took into consideration one occurrence.

First lets have a look at the algorithms being used:

As you can see the most used algorithm is RSA with SHA1 as a hashing algorithm but nearly one every 5 uses MD5 as a hashing algorithm. 
The strongest hashing algorithm found was SHA256 (1 occurrence, removed from the char) and the weakest MD5. It´s remarkable to see a 6% of DSA which is a n algorithm rarely used for X509 certificates, although perfectly valid.

Regarding key sizes for RSA we have the following distribution:

The most used key size is 1024b. Although I removed them from the pie charts, the weakest key size was 1023b (9 occurrences) and the strongest 8192b (1 occurrence). 

Developers, and some sysadmins too, tend to see digital certificates, and everything else around it, private keys, Root CAs, CRLs, etc as an annoyance and in the best cases as another “configuration” file.   Having in mind that Android forces you to use selfsigned certificates valid until 2033 it would be good to invest some time explaining developers the importance of the certificate/key and even more important enforce the use by default of stronger algorithms. Seeing the capabilities of the platform I don´t understand why Google did not enforce a minimum key length of 2048b and SHA1 or even better SHA256, instead of using default weaker settings especially when forcing developers to generate certificates valid for so long.

17 February 2011

How to validate the Subject Key Identifier (SKI) from a X509 certificate

Some days ago I received an odd complain that some of the Root CAs we use had the wrong Subject Key Identifier (SKI). I knew that the claim was false but I also knew that I'll have to prove it. The guy did dig on our own specifications and calculated the SKI as we required, the hash of the certificate public key but unfortunately the identifiers did not match.

In order to reproduce the problem I extracted the public key of the Root CA, converted to DER, hashed it with SHA1 and verified that indeed the hash did not match. Let’s do a demonstration of what I did with a public available Root CA:



Now let's calculate the SHA1 of the public key:



As reported, both hashes did not match!

At this point I was a bit confused and decided to read some documentation before moving forward. After some reading I found the answer in the 4.2.1.2 section of the the RFC3280 “Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile ” (http://www.ietf.org/rfc/rfc3280.txt)



In our case we use method 1) for the SKI but in my calculations I was taking into consideration the whole public key, including tag, length, etc, while I should have used the key bits only.
With the following command I was able to locate the “BIT STRING” with the naked key:



And I only need to extract it and put it on a file in DER format:



The remaining part was to calculate the SHA1 hash which was the same as the SKI:



The same method was used to verify the SKI of a Root CA using SHA256 as a hashing algorithm.