The evils(?) of self signed certificates

Posted by Walter Goulet on March 2, 2011 No comments

I consider myself largely a lurker on most security mail lists that I subscribe to, including the closed SANS Advisory Board mail list. However, a recent discussion on that list prompted me to think about the supposed risks of self signed certificates, especially in an enterprise network.

Like nearly any other security technology out there, self signed certificates can be evil or perfectly acceptable depending on the context in which they are used. In a nutshell, self signed certificates alone provide confidentiality and integrity to any protocols which use them to establish connections. Self signed certificates alone do not provide authentication in the traditional sense of a PKI, because the certificate has not been issued by another trusted party (such as a centrally managed PKI infrastructure).

So, the question is, does this lack of authentication make self signed certificates evil? I don’t believe that it does. A certificate can be authenticated by other means. For example, if the self signed certificate is installed on a end user system by some other trusted mechanism (such as a centralized directory/management server), the centralized management server is vouching for the self signed certificate. In another extreme example, a user could contact the administrator of a system that is using a self signed certificate and verify the certificate fingerprint being presented by the self signed certificate.

The real risks of self signed certificates are that end users will become accustomed to simply adding self signed certificates to their browser’s trusted certificate store and will ignore the security warnings presented by their browsers over time. The sanctity of browser errors generated by untrusted certificates must be preserved to ensure that users view those errors as exceptional events and respond accordingly.

The Chicken and the Egg Problem; Trusting Wireless Networks

Posted by Walter Goulet on December 1, 2010 No comments

It’s been quite a while since I’ve posted; since then my job has changed and I’m back to system design work. In my new role, one of the problems that I’ve had to solve recently is a familiar chicken and egg problem that anyone who’s had to deploy wireless networks that use enterprise authentication methods (EAP-TLS/EAP-TTLS) has had to face.

The issue surfaces when using an enteprise authentication method that relies on X.509 certificates for server authentication (like EAP-TLS, EAP-TTLS, and PEAP). When a wireless device (here wireless can mean WLAN and wireless broadband technologies) connects to an AP and begins the authentication process, the supplicant on the device needs to verify that the authenticator (typically the RADIUS server behind a wireless AP) is a trusted endpoint. This is done by verifying that the authenticator’s X.509 certificate has been issued by a trusted root certificate authority and is valid (digital signature is valid, cert hasn’t expired, plus any other local policy checks). However, these checks won’t properly handle the case where the authenticator’s certificate has been revoked by the issuing CA. While this is a low risk in most enterprises, in high security or mobile deployments (like the system I’m currently working on), the risk of the AAA server being compromised may be great enough to justify implementing some sort of countermeasures. The typical solution for checking for revoked certificates is to use certificate revocation lists or online certificate status protocol (OCSP). However, both of these methods are problematic in a wireless system for different reasons:

  • CRLs have a defined validity period after which the CRL should no longer be trusted (certificates revoked after the CRL expiration date will naturally not appear in the CRL). While this is normally not a problem, if a wirelss device does not attach to the network regularly, it could potentially fail to download new CRLs and cause the existing CRLs on the device to expire.
  • OCSP is a simple request/response protocol where a device can send a request to a OCSP responder immediately after obtaining a certificate to check that the certificate is valid. However, during the wireless network entry process, the wireless device has to trust the authenticator’s certificate to even obtain an IP address which means that the device cannot use OCSP to validate the certificate until it has already ‘trusted’ the certificate (hence, the chicken and egg problem).

There are a couple of solutions to this problem; ask the authenticator to contact an OCSP responder on the device’s behalf to find out if the authenticator’s certificate has been revoked, or connect to the network temporarily to download CRLs and then reconnect to the network to validate the authenticator’s certificate with the newly downloaded credentials.

The first solution above is implemented via a technique called OCSP Stapling (RFC 4366). OCSP stapling defines a means for an authenticator to contact an OCSP responder to get a OCSP response containing the server certificate’s revocation status. Wireless supplicants which support OCSP stapling will then expect to get a OCSP response in the certificate payload messages that they obtain from servers. However, OCSP stapling is relatively new and has not been widely deployed.

The second solution is somewhat more attractive than OCSP stapling because it does not require the authenticator to implement any additional functionality and requires only minor changes in the wireless supplicant. In this solution, the wireless supplicant will first connect to the network and will trust the authenticator’s certificate for the purposes of obtaining CRLs (or to optionally contact a OCSP responder and cache the response). After the supplicant has obtained the revocation information, the supplicant will immediately disconnect from the network and will peform another wireless association and authentication sequence. However, this time the supplicant can use the freshly obtained revocation information to validate that the authenticator’s certificate has not been revoked before permitting full network entry.

Neither of these solutions are perfect of course; they both require the wireless supplicant to trust the authenticator to a certain extent and don’t protect against the threat where the wireless device is associating with a “complete” rogue wireless network (where the AAA server, DNS server, CRL server and OCSP responder functions have all been spoofed). However, in both cases the overall system security has been improved rather significantly by providing a way for wireless network operators to revoke AAA server certificates with assurance that wireless supplicants will just ‘do the right thing’.

Quick and Easy Portable Media Encryption

Posted by Walter Goulet on February 25, 2010 1 comment

As part of my personal service delivery process, I have a need to store sensitive information for client engagements (vulnerability assessment results, network diagrams etc). To avoid having a dependency on specific test systems, I prefer to use portable USB drives to store data in the event that I need to switch to another system. However, I don’t want to risk losing this drive with confidential data on it. My solution is to create an encrypted partition on the disk in such a fashion that I can quickly mount the drive on another system without downtime.

To meet these requirements, I use a combination of Dropbox (http://www.dropbox.com), Keepass (http://keepass.info/), and Truecrypt (http://www.truecrypt.org/). I use Dropbox as a portable ‘Program Files’ directory where I install portable versions of Keepass and Truecrypt. This allows me to have my ‘Program Files’ directory replicated on all systems where the Dropbox client is installed (for backup purposes, I usually have my Dropbox account synchronized to 2 different systems).

I use Truecrypt to create an encrypted partition on the USB drive (using AES for encryption and HMAC-SHA-512 as a hash algorithm). The volume key used to encrypt/decrypt the partition is then stored as a password in my Keepass database (which is also stored in my Dropbox).

As long as the Dropbox is synchronized between my test systems, switching from one system to the other is as simple as plugging the USB drive in and launching Truecrypt/Keepass from my Dropbox.

Here’s my step by step instructions to replicating this setup on a Windows XP/Vista/7 system (I assume you already have Dropbox installed on your system):

  1. Create a ‘Programs’ directory in your Dropbox folder. In this folder, create 2 subdirectories, ‘Keepass’ and ‘Truecrypt’.
  2. Copy the portable versions of these programs into their respective folders (Truecrypt does not have an explicit ‘portable’ distribution, rather download the setup file here and choose the ‘Extract’ option when running the setup, Keepass on the other hand provides a portable version that can be downloaded here).
  3. Launch Keepass and create a new password entry for the portable drive. I suggest using the Password generator function to generate the password. Note that since this password is used as an encryption key, I recommend selecting all available characters for generating the password and using the maximum key length (64 characters).
  4. Plug in the portable USB drive that will contain the encrypted partition (note: this has only been tested with USB hard drives; I have not tested this with smaller USB flash drives).
  5. Launch TrueCrypt and use the ‘Create Volume’ button to launch the new volume creation wizard. I recommend writing down the path to the volume being created to make it easier to mount later. For my personal setup, I chose to create a regular (non-hidden) partition using AES and SHA-512 for encryption and as a hash algorithm. When prompted for the volume password, use the password entry created in Keepass.
  6. The volume is now created!

To actually mount the encrypted partition, start Truecrypt and select an available drive entry. Select the encrypted volume from the Volume list then click ‘Mount’. When prompted, enter the password from the Keepass password entry.

Note that regardless of which system was used to create the encrypted partition, you can mount it on any other system as long as you have access to Truecrypt and your volume password.

Integrated vs. Standalone RADIUS Servers in WLAN Deployments

Posted by Walter Goulet on June 29, 2009 2 comments

Several popular WLAN infrastructure vendors include lightweight RADIUS servers directly in their access points. These lightweight servers are typically designed for use by vendors as a backup solution in the event that connectivity to an off-board RADIUS server is lost.

I recently had the opportunity to speak with a WLAN network administrator and we briefly discussed the merits of using an integrated RADIUS server on APs vs using an external RADIUS server for authentication. After thinking about it for a few days, I realized that relying solely on the integrated RADIUS server for wireless authentication is rarely a good idea.

  • Integrated RADIUS servers on APs are typically minimal servers that are designed to serve a small number of clients. If the WLAN network grows in size, the number of users that will need to be configured could easily exceed the limits of the integrated RADIUS servers.
  • Some integrated RADIUS servers do not offer support for accounting services. This can be either a non-issue or a serious disadvantage depending on the purpose of the WLAN.
  • Integrated RADIUS servers typically use proprietary local database engines/management interfaces to administer the user database, which makes it difficult to do certain operations like import/export user databases between APs or switch to APs from a different vendor.
  • Standalone RADIUS servers offer advanced capabilities such as integrating with LDAP or Exchange servers to provide single sign-on capabilities. Integrated RADIUS servers in APs don’t have such capabilities due to the complexities and necessary protocol support required to interact with other authentication servers.
  • Integrated RADIUS servers can only support the EAP methods that are built into it, restricting the set of EAP methods that can be used in the WLAN. Standalone RADIUS servers can typically support a much larger number of EAP methods and therefore provide the WLAN administrator with a great deal of flexibility. Note that APs which are acting only as a NAS are only relaying EAP messages between clients and the RADIUS server and therefore don’t need to have support for the different EAP types built-in.

However, even with all of the advantages a standalone RADIUS server offers over an integrated RADIUS server, there are some compelling advantages of the integrated solution: the integrated server is likely only to fail when the AP itself physically fails, the authentication sequence may be slightly faster since there is no extra hop between the AP and a RADIUS server, and of course it doesn’t require any additional capital expense for your network. In short, the decision between a integrated and standalone server solution should carefully consider short term and long term costs/network growth as well as flexibility in supporting both existing and future requirements of the network.

HIPAA – Technical Safeguards

Posted by Walter Goulet on February 17, 2009 No comments

A large part of my job requires me to dig into security standards to help figure out how to create consulting services to assist customers with achieving compliance. One standard I’ve never looked into before is HIPAA (Health Insurance Portability and Accountability Act of 1996). HIPAA is not a security standard per-se, but rather a set of administrative rules established by the US Department of Health and Human Services to govern how health information is accurately and securely exchanged between medical institutions and other institutions that have a legal need to access patient medical data.

HIPAA is encoded in the US Code of Federal Regulations, Title 45, Parts 160, 162 and 164 (see here for the CFR). Section 164 is the most interesting section for a security professional, as this section describes the security and privacy requirements that must be satisfied by organizations that must comply to HIPAA regulations (these entities are called ‘covered entities’). Unfortunately, Part 164 is further divided into 31 subsections that define the actual security requirements. Rather than digging into each of these sub-sections, I’m going to focus on sub-section 312 which defines the technical safeguards that must be implemented by covered entities. Subsection 312 specifies 5 standard safeguards: access control, audit controls, integrity, person or entity authentication, and transmission security. The code further specifies implementation requirements for each standard. The following mindmap graphically illustrates Subsection 312.

Mindmap of CFR 164, Section 312

Mindmap of CFR 164, Section 312

As far as legislation goes, the HIPAA Technical Safeguards are fairly well written in terms of striking a good balance between actionable requirements with room for interpretation to make the standard independent of changes in technology (for example, the Encryption safeguards do not name specific encryption algorithms that need to be used). However, the Safeguards are too vague to use alone. Therefore, NIST prepared a Special Publication, SP800-66 Rev1 (found here), that can be used to help interpret the safeguards by mapping them to specific controls described in NIST documentation. In a future post, I’ll further examine NIST SP800-66 and attempt to summarize some of the specific security controls to implement the HIPAA Technical Safeguards.

Hashes – not just for breakfast

Posted by Walter Goulet on January 28, 2009 No comments

Consider the problem where you need to know for sure that information you are looking at has not been altered since it was first created. A simple example that kids can relate to is a report card from school. The model for report cards is that the school gives a kid his/her report card, they bring it home and their parents sign it to show that they read the report card. An obvious problem that the school has is to be certain that the report card isn’t changed while the kid has it.

In cryptography, this problem is referred to as ‘data integrity.’ Cryptographic systems solve this problem by creating a representation of the information that is unique. This representation is referred to as a ‘hash’ (or checksum). A good way to think of a hash is as a digital fingerprint that looks totally different for each set of data that it represents. Functions that are used to create hashes from information are called hash functions. There are a couple of important points about hash functions:

  • The result of the hash function MUST be unique for each message that it processes. That is, you should never be able to get the same result from a hash function if you feed in two different messages.
  • The result of the hash function MUST not look anything like the message that it processed.
  • It MUST be impossible, given the result of a hash function, to determine what the original message was.
  • The result of the hash function is usually smaller than the message that it processed.

If you wanted to exchange a message with another person and be sure that the message hasn’t been changed along the way, you could use a hash function as follows:

  1. Create a message.
  2. Feed that message into a hash function.
  3. Send the message to the recipient along with the hash.
  4. The recipient feeds the message into the same hash function used by the sender.
  5. The recipient compares their hash with the sender’s hash. If they are identical, the recipient is sure that the message wasn’t changed.

Of course this exchange isn’t secure as the hash could be changed in transit as well, but it illustrates how such a system works. I’ll explain how to make this exchange secure in a future post. To find out more about the basics of hash functions, read more.

Read more »

Clock arithmetic and security

Posted by Walter Goulet on January 21, 2009 No comments

Quick quiz, what do the following sequence of numbers have in common: 19, 3763, 31, and 67? The answer is, they are all the same! Ok, well obviously that’s not strictly true. More correctly, these numbers all represent the same value in modular arithmetic (7 modulo 12). When you take each of these numbers and divide them by 12, you end up with a remainder of 7 (19 / 12 = 1 remainder 7, 3763 / 12 = 313 remainder 7, 31 / 12 = 2 remainder 7, and 67 / 12 = 5 remainder 7).

Another simple way to think of modular arithmetic is clock arithmetic. Consider the problem when you are looking at an analog 12 hour clock. You need to figure out what time it is going to be 7 hours from now. If the current time is 3 o’clock PM, you add 7 hours and end up with 10 o’clock PM. But, what if it’s 8pm? You don’t simply add 7 hours as there is no such thing as 15 o’clock pm. Instead, when you pass 12 o’clock AM, you restart your counting. So 8 o’clock PM + 7 hours = 12 o’clock AM + 3hrs = 3 o’clock AM.

So what does clock arithmetic have to do with security? Going back to our original sequence of numbers, notice that you cannot possibly determine that these numbers all represent the same mathematical value without having a key piece of information, the modulo value (which in this case is 12). When you think about it, this property is useful from a secrecy perspective because you have 2 pieces of information that have a common value, but you can’t tell what that common value is unless you know some other information. This basic property of modular arithmetic forms the basis of many of the key negotiation and encryption algorithms in use today.

So, for fun, here’s a simple cryptosystem (secure enough to keep your 10 year old little sister from reading your journal) that uses this property. Note this cryptosystem doesn’t authenticate the two parties, but it at least allows them to exchange a pair of secret keys no matter who is listening.

  • Alice and Bob want to exchange a secret message, but they can only talk to each other over an open communication channel.
  • Beforehand, Alice and Bob agree to use the current time as the modulo value for determining the secret value. For example, if the current time is 4pm and Alice and Bob want to agree on a secret key, they will divide their values by 4. Note that the method they are using for choosing a modulo value must remain secret for this system to work.
  • Alice sends her value to Bob in an open channel. Bob calculates the value she sent modulo the current time. The result is Alice’s encryption key.
  • Bob sends his value to Alice again in an open channel.
  • Alice calculates the value she got from Bob modulo the current time. The result is Bob’s encryption key.
  • Now, Alice and Bob can communicate securely using each other’s encryption key to encrypt messages being sent back and forth (using some pre-determined encryption algorithm).

To see the system in action:

  1. The current time is 9pm.
  2. Alice picks a value of 84.
  3. Bob picks a value of 1156.
  4. Alice and Bob send a message to each other via a open channel (normal phone call, ads in the newspaper, or even yelling at each other in a park!).
  5. Alice get’s Bob’s value of 1156 and calculates 1156 / 9 = 128 remainder 4. 4 is Bob’s encryption key.
  6. Bob get’s Alice’s value of 84 and calculates 84 / 9 = 9 remainder 3. 3 is Alice’s encryption key.
  7. Now Bob and Alice can encrypt their messages using their respective encryption keys.

The real beauty of this type of system is that no matter who learns the values that Alice and Bob selected in steps 2 & 3, they will never be able to figure out how they are related without knowing what the modulo value is. In a future post, I’ll expand on this a bit more to show how modular arithmetic is used in non-toy cryptosystems.

Summarizing PKI Certificate Validation

Posted by Walter Goulet on January 19, 2009 16 comments

Security certificates and the methods used by websites to show that they are secure enough for users to trust are notoriously complex. To shed a little light on this, I’m going to explain how PKI certificate validation works.

PKI (Public Key Infrastructure) describes a method of asserting the identity and validity of a person (or entity) that you have not previously met or interacted with through the use of certificates containing identifying information and public keys (these certificates are more properly called X.509 certificates). PKI accomplishes this by defining a central authority who is mutually trusted by all users of the system. The following logical diagram shows how this works for a scheme where I am presenting my credentials to a user to setup a trusted communication path between us.

Simple PKI Diagram

Simple PKI Exchange

As shown in the diagram above, the burden of figuring out whether or not a certificate can be trusted ultimately falls on the end user. The user is responsible for going through the step of verifying a certificate with a Certificate Authority to figure out if the certificate presented to him is valid. Ultimately, it is the software used by the user (mostly web browsers) that perform this validation.

Before describing the certificate validation process, let’s spend a few moments first describing what a X.509 certificate contains. In short, a certificate contains information identifying the owner of the certificate, an identifier of the central authority that issued the certificate, a unique serial number, a validity date range, and other optional fields that indicate how the certificate can be used. In addition to this information, a X.509 certificate contains information needed to verify the integrity of the certificate such as a public key that is owned by the certificate owner and a field describing the hash and encryption functions used to create the digital signature of the certificate. The digital signature is an encrypted one way hash of the certificate contents. This signature is created using the private key of either the certificate owner or, for certificates issued by a Certificate Authority, the private key of the Certificate Authority.

Certificate validation, described in RFC 5280, is notoriously complex due to issues of backwards compatibility with older X.509 standards, overloading the meaning of fields contained in certificates, and other technical issues. That being said, it is still easy to describe the overall process used by end user software to perform certificate validation.

The first step of validating a certificate is to first verify the certificate’s integrity. This is done by first creating a one way hash of the certificate contents (using the hash algorithm indicated in the certificate). This hash is stored temporarily in memory. Next, the digital signature embedded in the certificate is decrypted using the public key included in the certificate (or, for CA issued certificates using the public key from the CA root certificate). The decrypted digital signature (which is again a hash of the certificate contents) is then compared to the hash that was computed locally. If the hashes match, then the user knows that the certificate has not been altered since it was created.

Next, the certificate is checked to ensure that it has not expired. This is done by verifying that the current time falls within the validity dates included in the certificate. Next, the certificate usage fields are checked to ensure that the certificate is being used for the purpose it was intended (via the keyUsage field). For example, if the keyUsage field of a certificate is set to cRLSign but the certificate is presented by a bank website, the certificate is not being used as intended and will be rejected. Finally (and probably most importantly), the certificate is checked to see that it has been issued by a trusted certificate authority.

This last step bears more discussion as it is the validation step that is most important in trusting a certificate. An important field embedded in a X.509 certificate is the issuer field. The issuer field lists the name of a certificate authority which has vouched for the validity of the certificate. Recall the step where the integrity checks are performed. The user must decrypt the digital signature using a public key. Instead of using the public key embedded in the certificate, the user looks at the issuer field to identify a Certificate Authority certificate (called a root certificate) that contains the public key that should be used to verify the certificate. The root certificates are stored locally on the user’s computer, so the software searches through this list to fetch the correct root certificate. Once the root certificate has been found, the public key from the root certificate is used to decrypt the digital signature in the certificate being validated. If the signature is validated, the user knows that the owner of the root certificate (the Certificate Authority), has signed the certificate being presented and therefore vouches for the contents of the certificate.

At this point, the only remaining step is to see if the certificate has been revoked by the Certificate Authority (due to a possible compromise of the certificate or of the Certificate Authority itself). Since the list of root certificates that are stored on user’s computers are not frequently updated (the list is usually selected by the OS or browser vendor), there must be a way for the software to dynamically query the Certificate Authority to check if there is a problem with the certificate. This is accomplished using 2 different techniques: certificate revocation lists (CRLs) and an online check called Online Certificate Status Protocol (OCSP).

CRLs are lists that are periodically issued by a CA that contains a list of certificate serial numbers that have been deemed to be invalid by the CA. The CRL also contains a date range indicating when the CRL should be considered expired and a new list should be obtained. Browser software is expected to regularly download the CRLs for all root certificates that it has knowledge of. When using CRLs, the final check for a certificate’s validity is to verify that the certificate’s serial number does not appear in the latest CRL for the CA.

OCSP is a protocol that is used by browser software to query a CA dynamically for the revocation status of a certificate. The query request contains the serial number of the certificate being checked as well hashes of the issuer name and public key. The request is sent to a OCSP server operated by the CA. The response will either indicate that the certificate is valid, revoked, or is unknown. When using OCSP, the final check for a certificate’s validity is to verify that the CA’s OCSCP server reports back that the certificate is ‘good’.

In summary, the certificate validation process is complex and resource intensive. The PKIX community has recognized this as becoming more of a problem with the prevelance of mobile devices that have limited processing resources. A solution that is being proposed is a mechanism to offload the responsibility of performing all of the certificate validation steps to a centralized server that is trusted by users. This mechanism is called Server-Based Certificate Validation Protocol defined in RFC 5055. In a future post, I’ll examine more about SCVP and discuss different use cases for how it can be deployed to provide security in mobile wireless networks.

The case (for/against) filtering subscriber to subscriber network traffic

Posted by Walter Goulet on December 31, 2008 No comments

Part of my job is to help customers decide when and where it’s appropriate to deploy firewalls and other security devices in their networks. One point that has come up in discussion with my colleagues has been whether or not it is a good design principle to filter peer to peer traffic in service provider networks. Let me first clarify what I mean by service provider networks. I am referring to networks that are specifically designed to provide connectivity for subscribers, either to the Internet, to private intranets, or to each other. The owner of this network (the service provider) is essentially providing ‘pipes’ for his customers. Service providers earn money by creating and meeting service level agreements (SLA) with subscribers that guarantee bandwidth and availability to customers.

I define subscriber to subscriber traffic filtering as a network design which explicitly prohibits the exchange of packets directly between subscribers without first passing those packets through a firewall or access control lists. An example of this type of network is a typical cable or DSL service network provider where subscriber packets are filtered through a network access server (NAS) prior to being forwarded to their destinations. A metro Ethernet network is an example of a network that does NOT perform peer to peer traffic filtering (metro Ethernet provides layer 2 connectivity between subscribers).

From a pure service provider business perspective, you care little about the types of traffic that subscribers exchange as long as you are able to meet the SLAs that you have established. If the traffic that is exchanged happens to contain malicious information (viruses, malware etc.), the service provider isn’t really going to care as the type of traffic exchanged doesn’t affect their ability to provide service to subscribers.

From a subscriber perspective, you care a lot about whether or not your home/business network is subjected to malicious traffic originating from your outside network connection. However, you also care about having the freedom to use your outside network connection as a raw pipe and being able to exchange any kind of network traffic with anybody that you can connect to (especially home users who use BitTorrent and other P2P protocols).

From a regulatory perspective, as a service provider you care about meeting the legal requirements to provide service in the regions you operate in order to avoid penalties etc. Certain governments impose restrictions on the types of traffic that network users are allowed to exchange (China being a prime example with strict requirements on which websites can be viewed by Chinese residents).

As can be seen from these 3 different perspectives, the need to implement filtering controls to restrict subscriber to subscriber traffic is not immediately evident. From a security threat perspective, most service provider networks are designed to provide clean seperation of bearer data (subscriber traffic) and control/management data used by the provider to run their network. So the risk of subscribers actually accessing the service provider’s infrastructure is quite low. A slightly more obvious security threat is the risk of being non-compliant to regulatory requirements. In this case, the risk of non-compliance can be quite high depending on each country’s regulations.

In conclusion, when considering whether or not to implement peer to peer traffic filtering and whether or not the lack of this filtering is a security risk, consider the network design and the regulatory requirements governing the network operation. You may be surprised to find that there is in fact little to no security risks to the service provider by NOT performing peer to peer traffic filtering.