PGP Blogs

Data Security Is Not Just for the Big Guys
Tuesday, March 23rd, 2010

I recently had an interaction that reminded me  how much more work we have ahead of us in making people aware of the security risks associated with data breaches. My son is a member of well known youth group. Recently during an event, one of the volunteers came snapped a photo of his face. She informed me that this was for their local database to “make it easier to know who is who”. I asked her how they had planned to secure this data and if I could get a copy of their privacy policy as well as some information on their data destruction policy.

I forgot that not everyone who manages data even begins to understand the risks. It’s one thing to maintain contact information for members, it is another thing to add photos to it, especially when children are involved. I tried to explain that I was concerned that without any privacy policy in place (not to mention security process) that there was no way to ensure that this data would not spread to anyone who had nefarious intent, either through negligence or simple lack of education. Neither she nor her boss had a clue what I was talking about. I immediately asked her to delete the photo from her camera. In fact I suggested that I was willing to help formulate a security policy to help decrease their exposure.

Unfortunately my concerns were misconstrued to being “negative and overbearing”. I was reminded that they all agreed that this was a useful thing to do. I am sure that was a time when the introduction of seat-belts were considered just as intrusive, or maybe people had more sense then. Such is life, when you deal with bad guys all the time, it’s sometimes hard to remember that not everyone has the same perception and awareness of risks.

My real concern is not so much that the data would be misused but that without proper safeguards that it could be misused. It is not hard to imagine the database being picked up in a theft and getting ultimately getting used by a child abductor to shop their victims. Now understand, I am not trying to come across as a paranoid parent, but rather looking for sensible safeguards.

While my concerns fell in deaf ears, the lesson to me was clear. Small organizations share many of the same risks common with enterprises, but are typically unaware of any the exposure until it is too late. They can, however,  benefit from all the work done to protect the big guys. In this case, a little policy writing and possibly some off the shelf encryption technology would probably suffice.

Filed under: Vinnie's Views
Tags: Data Breach, Privacy Policy
Comments: No Comments

Trust Us, It’s Secure Encryption Technology
Wednesday, May 13th, 2009

Unsolicited, my bank recently sent me a shiny new debit-card in the mail. They kindly included a note explaining that they were notified by a “major credit card processor” about an unauthorized intrusion (what’s an authorized intrusion?) into their computer system and as a result my account information may have been compromised.  To ensure the security of my account they were taking the proactive step of issuing me a new card with a new number and that I would have to activate it within 10 days.

Fair enough, these things happen. They were trying to move forward. But then I noticed that this debit card now has this added “feature”; an RFID chip I can use at checkout to send payment details wirelessly to the processing network (that previously had the intrusion), without troubling me for a signature or PIN for any amounts less than $25.

Hmm, my spider senses tingled as I seem to remember something related to privacy issues and RFID. It’s been a while since I overhauled the tin foil on my gourd and I needed to do some catchup. I dropped by the local bank branch and asked the manager if he knew anything about what kind of technology was involved in this card. He hadn’t even heard of RFID, and I didn’t really expect him to. But, he did some web searching and found an FAQ that should put me at ease, it stated that the card was safe to use, because it employed “secure encryption technology”, you know like that TV show, 24. Wow, I thought, I gotta get me one of those. Eventually we contacted the card vendor and asked if they could provide us some more information about this “secure encryption technology”. Guess what? They told me, it was proprietary and that I should trust them, (did I mention about the “unauthorized intrusion”).

Either way, not being really comfortable with the answers I was getting, and apparently I wasn’t the only one on the net with these feelings.

So, I asked if I could opt out of this feature. They informed me that this was not possible, and that (surprise) these new cards were actually more secure. Oh, and they mentioned that this will soon be available in a wristband form to facilitate the purchase of beer and hotdogs at sporting events, so I could get back to watching the game quicker.

Just ignore the man behind the curtain.

Now I am sure I don’t need to bring up the issue of “secret” encryption technologies to this audience. Let’s just leave the beating of that zombie horse to another blogger who’s much better known than I. In fact, I personally can even accept weak or no crypto for the card if the credit card company is willing to take reasonable liability for it. In addition, I know that the effective usable distance of these kinds of RFID chips are pretty much limited to a distance of about an inch and a half. And yes, I am aware of some cool attacks on these devices, but this is not one of my bigger concerns in life.

What really bothers me is that the card vendor is trying to shove this technology down my throat without offering any reasonable way to opt out. The more I think about it, this privacy invasion creep seems to be happening all the time.  Cars that can be remotely unlocked from the factory, cell phones record your GPS coordinates, and satellite TV providers want to charge more if you don’t allow the set-top box to call them to report usage data.

I can empathize with motivation behind all these “features”. Some of it is marketing driven, and some is an attempt at product differentiation in a tight market. However, I would really like a bit more information detailing the steps they are taking to protect my privacy. It’s not like I am asking them to publish the source code, or even write an assurance letter.

In the meantime I found some tinfoil for my wallet, worse case I suppose I can just take a ball pein hammer to the chip.

Filed under: Vinnie's Views
Tags: privacy intrusion, RFID, secret encryption
Comments: 1

Send Lawyers, Spies and Log Files
Monday, May 11th, 2009

As more of our data migrates up to the internet cloud, I am becoming profoundly aware of the unintended consequences and risks posed by so called best practice security procedures. Today I would like to discuss the server access logs that record IP address of network clients. Companies keep these logs for any number of reasons, from lead development to intrusion detection. While there has been much discussion both from law enforcement and various civil liberty groups on how long these logs should be kept and whether they should even exist at all, often the focal point of the conversation is governmental intelligence gathering. However, I would argue that the greater risk stems from global economic espionage and/or compliance with possible civil discovery subpoenas.

Economic Espionage (as defined in Title18 U.S.C., Section 1831) occurs when someone knowingly performs targeting or acquisition of trade secrets to knowingly benefit any foreign government, instrumentality or agent. This kind of espionage is most frequently reported as incidents of laptop disks being imaged while the owner is absent from their hotel room; quite easily mitigated, by the way, with judicious use of software such as PGP Whole Disk Encryption.

What I’m really concerned about, however, is the damaging information that can be assembled by performing traffic analysis on a web service access log. The ability to examine who was looking at a server and what they were looking at is a powerful intelligence tool and can greatly assist piecing together the rest of the story. Imagine for example how useful it would be to know who a competitor is emailing, even if you can’t see the contents of the mail messages.

While it has been documented that a number of governments employ web filtering or even parental control tools to keep track of their citizens ventures in cyberspace, what is not often discussed is that there are governments (including a few that you would think of as friends) who have put both personal and legal pressure on key individuals from U.S.  corporations ranging from executives to system administrators to hand over information sub rosa including access logs. It’s amazing what the threat of a few nights in a foreign prison will garner you.

A less intriguing but just as problematic threat, is the requirement to comply with a civil court e-discovery subpoena. The example that comes to mind involves an aggressive attorney wanting to piece together a story about infidelity for divorce proceedings. Items such as video camera logs from shopping malls and email delivery logs (in absence of the mail content) can be often be decisive in these cases. I imagine that the cost to comply with these subpoenas can quickly add up if you are handing a large number of customers, especially once precedent is set with successful cases.

Both of these scenarios have a similar defense in common, you are less likely to be compelled to release information that you don’t have. With this in mind, there are a few simple things you can do to your IP address log files from attracting interest:

Decide to not keep logs, or keep them only for a short period of time (72 hours for instance). This gives you time to research ongoing threats, but limits historical data mining. If there is aggregate traffic data you want to track, then anonymize it before archiving. Rather than secure wiping the logfile, create it on a virtual disk encrypted to an ephemeral key. You can use the pgpdisk command line utility on OS X with the “onetime” option to create a disk with a strong random key that is wiped when the disk is dismounted. Regardless of what policy you adopt, experts suggest you make public your policy about log disposal to prevent you from being drawn into potential legal actions.

You might ask what got me thinking about logs all of a sudden. To be truthful I had a conversation with the owner of a politically sensitive web forum about the anonymity of his participants. He was concerned that recent discussions of internet privacy would have a chilling effect on his forum, scaring away potential customers. He would rather that the subject not come up at all. I explained that experience has shown that this security strategy has not been very successful in the past. A better approach is to be up front about the risks and make your policy public. While tracking the IP address of posters is useful for identifying and locking out trolls, there is no reason to keep the IP addresses around of other posters for any period longer than necessary. This requires some work on his part but also yields some major rewards in reputation capital.

The task of preventing this exploit is not limited to the server provider. I would also encourage client software developers to consider making their code Tor friendly to enable the anonymization of IP addresses. This might be as simple as checking for Tor installation and supporting the socks protocol. Further as most software users exhibit a fair mount of functional illiteracy when it comes to security, it helps to front end a simple user interface that works with the Tor client and offer the use of Tor as a part of their best practices documentation.

This is all stuff worth considering, and while it might not be possible to venture out into the internet cloud with an honest “leave no trace” guarantee, we can at least try and clean up as much as possible leaving little that can be used against us.

Filed under: Vinnie's Views
Tags: Economic espionage, log files, PGP Whole Disk Encryption, pgpdisk, TOR
Comments: No Comments

Stimulating the Security of Medical Records.
Tuesday, February 17th, 2009

One of the items in the economic stimulus package signed by President Obama today that has not received much publicity, but at the same time  prompted a fair amount of hand wringing is the provision for facilitating nationwide electronic exchange of health information.  Last I checked there was $20 billion proposed for standardizing electronic records for health related information including  patient demographics and clinical health and medical history data. This health data should be easily transmitted and exchanged with  various health care providers.  The overall goal is that each person in the U.S. would have certified electronic health records by 2014.

Some of that is carrot and stick. There seems to be money available for doctor’s offices and hospitals for moving from paper based records to electronic form and also some possible penalty for not.

On the positive side, there are some provisions that the patient be notified in the case of unauthorized disclosure of their records, as long at the data is unencrypted.  There is also some wording about the  prohibition on the sale of protected health information.

On the other hand, this also creates a new threat model and there is extensive potential for misuse of this data.  While private sector misuse will most likely be addressed by legislation similar to Sarbanes-Oxley, it is not clear what protections will be put in place to protect from misuse by government entities.

For now I  am going to  reserve  judgment on this, but I will say that I am concerned about the potential risks to the civil liberties of  future generations.  I would have preferred that these issues were discussed a bit more in the forefront rather than being tacked on as a rider by Congress.  This all reminds me  of  Otto von Bismarck’s quote “To retain respect for sausages and laws, one must not watch them in the making.”  In the meantime, I am planning to rent and re-watch a copy of Gattaca and consider what can be done with electronic medical records.

Filed under: Vinnie's Views
Tags: Gattaca, health care records, stimulus package
Comments: 1

Securing Content in the Clouds.
Tuesday, February 17th, 2009

I am impressed at how popular web applications have become in the last few years.  Not just web mail, but actual collaborative and analytical  applications.  Companies like Google, Salesforce, Apple, and Facebook have done an amazing job of migrating valuable user data to the clouds.  Not to mention the internet based backup systems.

Despite widespread use, the task of securing the data presented in web applications has largely been unaddressed.  Users of web mail (Gmail), forums, blogs and group calendaring (Google Calendar) currently have no reasonable way to ensure the privacy of their information, in that it often resides on the web server.   As an iPhone user I am very aware of this every time I sync up my address book or calendar. The data is protected on the move, but  I have no way to secure of the data once it reaches an Internet based repository.

Part of the reason is that these mobile devices present special challenges.  For example, Apple strictly limits what plugins can do to extend the iPhone.  I can empathize with their reasoning, malevolent code on a phone has the potential to cause extensive damage to both the user’s privacy as well as possibly the phone network.  But, even if these restrictions were made more reasonable, the current developer plugin architectures aren’t designed for securing data. I’d like to see this change.

I have done quite a bit of research on how to extend the web browser functionality  through plugins that can, for example, decrypt OpenPGP content. While this is a good start, it can only take us so far.  What we really need is for web application developers to understand the need for securing user’s content and to design in the proper hooks.    The same can be said for cloud based backup and sync systems.

Maybe this will happen as user’s become more aware of the data loss through security breaches, but I’d rather that we avoid those altogether by good design and forethought.

Filed under: Vinnie's Views
Tags: cloud computing, Data Security, Facebook, OpenPGP, Salesforce
Comments: 1

Some Thoughts About Facebook, OpenID and Secure Authentication
Thursday, February 5th, 2009

In an previous post I talked about the possibility of using a PGP key to provide secure authorization for web services. A story I read recently reminded me about how important strong authentication has become, even for trivial websites. The saga, which reads like a typical Nigerian 419 scam, starts when a hacker accesses Bryan Rutberg’s Facebook page and changes the password so he can’t get in. Bryan, by the way, is a senior director at Microsoft, so I assume he’s reasonably literate about computers. Yet his password is stolen. Now comes the fun part. The hacker updates the profile indicating that Bryan was mugged overseas and urgently needs someone to wire him money. The hacker even messaged his Facebook buddies attempting to scam them. Eventually Rutberg becomes aware of what is going on, he discovers the Facebook security page, but doesn’t get a timely response, and eventually finds a relative who knows someone on the Facebook team and gets the account disabled some 48 hours later.

I found the story amusing because  I was researching methods to secure web content. Content not unlike Facebook.  Indeed, I was curious about the method used to glean his password.  At first I suspected he employed a weak password, and this might be the case (it could also be a worm), but under further examination I found that the Facebook login has exploitable vulnerabilities. Once A hacker is able to obtain that email and password combinations, the chances are pretty good that they can be used to break into other services.

All of this continues to sour me on the use of passwords.  Fortunately, there is a possible solution to this whole mess that seems to be gaining traction these days.  OpenID, have you heard of it?  OpenID is a framework for managing user identity on the Internet.  It attempts to address the single sign-on problem; allowing you to log on to multiple web services with the same digital identity. With OpenID I should be able to log in to one place and then have access to my countless web services like Facebook, eBay, PayPal, online banking, etc. What’s more, OpenID removes the need for the web provider to manage the passwords.

Instead of specifying a username / password combination, a you enter the url of your OpenID Provider. Though the magic of browser redirection  you are then directed to login to your OpenID provider site,  then redirected back to the web service. If the you are already logged in, the authentication step is skipped.

What makes OpenID different from proprietary systems such as Microsoft Passport or Facebook Connect is that it gives user a choice as to whatever identity provider they wish to employ.  Well at least that’s how it is supposed to work. You can get an OpenID from Yahoo or Google, but as of now these sites don’t have a way to specify OpenID identities from anyone else but themselves. Oh and Facebook seems to be ignoring it now in favor of their own technology. I hope this all changes shortly. I suspect that even if FaceBook became an OpenID provider, they would suffer from the same customer service issues.

Why all of this matters to me is that while OpenID specifies how web services should talk to the OpenID provider, the protocol itself is open for third parties to implement their own authentication system. This is where it gets interesting.  Instead  of passwords, it is possible to use a strong authentication system  similar to the cryptographic challenge response method I blogged about earlier.  The only  password you would have to manage is the on you already  use for your public key. This also abates the possibility of an automated password attack against the web service provider.

More to come..

Filed under: Vinnie's Views
Tags: Facebook, Nigerian scam, OpenID
Comments: No Comments

PGPsdk and FIPS-140
Monday, September 15th, 2008

What is FIPS-140-2?

FIPS 140-2 is the Security Requirements for Cryptographic Modules standard from the National Institute of Standards and Technology (NIST). It applies to the protection of valuable and sensitive but unclassified information throughout the government and DoD. FIPS-140 is not a security guarantee but rather a set of best practices for implementing the cryptographic algorithms as well as handling the secret key material.

The primary objective of FIPS-140-2 is:

• Protection from unauthorized use.
• Protection of Critical Security Parameters (eg. Secret Key material)
• Protection from undetected modifications
• Use of approved security methods
• Indication of module operational standards
• Detection and indication of errors.

What is often misunderstood is that FIPS-140-2 only pertains to cryptographic modules (PGPsdk), not the products that use them. Further within the module is a subset of functions delineated in the Cryptographic Module Security Policy (CMSP) that excludes the non-cryptographic functions. Only the code within this cryptographic boundary is eligible for validation. So while we can put portions of the PGPsdk through validation we can’t validate PGP Desktop or PGP Universal Server.

What makes FIPS-140-2 so important is that compliance is mandatory for all US Federal Agencies, DoD, financial institutions, the Canadian government, and many private sector agencies when a Federal agency determines that cryptography is necessary for protecting sensitive information.

Levels and Sections

FIPS-140-2 has a number of security areas that must be addressed at the various levels. For each of these areas a module can receive a rating of 4 security levels and, in addition, the entire module will receive an overall level equal to the lowest level of all the areas. These levels are defined as follows:

1. Basic security requirements
2. Tamper evidence, role base authentication
3. Enhanced physical security, identity based authentication
4. Envelope and environmental protection

Only Level 1 and possibly Level 2 (in specific hw/sw combinations) are actually applicable to software modules such as the PGPsdk. Level 1 allows the module to be run on a general purpose computing system using an unevaluated operating system while Level 2 requires that the OS meets the requirements of Common Criteria EAL-2 and that it maintain a controlled access profile (TCSEC, C2, ITSEC, C2/E2, etc).

Level 2 further goes on to attempt to map the concept of tamper evidence and role-based authentication to a software module. In effect, it requires that the module maintain an audit log of all cryptographic operations, although it doesn’t require that this data be stored securely. There is also a requirement that the user authenticate itself to the crypto module before using it, in effect they would have to log in to the module.

For FIPS-140-2 we have opted to forgo Level 2 for, among other reasons, the belief that maintaining this log might open the user to a traffic analysis attack in addition to potential performance implications.

As mentioned earlier, the FIPS-140-2 specification is divided into 11 security areas that each module must address. Some of these areas are nothing more than documentation tasks, some are usage policies, and others require specific software functionality. These areas are defined as follows:

1. Cryptographic Module Specifications
2. Cryptographic Module Ports and Interfaces
3. Roles, Services and Authentication
4. Finite State Model
5. Physical Security (N/A)
6. Operational Environment
7. Cryptographic Key Management
8. EMI/EMC (N/A)
9. Self-Tests
10. Design Assurance
11. Mitigation of other attacks

Documentation and Software Requirements

The first four sections are mostly documentation tasks. The module specifications and ports and interfaces (aka API) are defined in the Cryptographic Module Security Policy (CMSP). The CMSP covers, among other things, the cryptographic boundary, the approved modes of operation including all hardware, software and firmware components, which library binaries contain the PGPsdk, what algorithms it supports, as well as what the Application Programming Interface (API) looks like.

The security policy for each version of the PGPsdk can be found in the developer package as well as the NIST website.

For Level 1, the Roles, Services and Authentication section is a documentation issue, covered in the CMSP, but for Level 2 this requires the operator to authenticate himself to the module before doing FIPS operations (ie key generation) that modifies, discloses or substitutes a CSP. or uses a FIPS approved security function. In effect, the operator would have to log into the PGPsdk.

The Finite State Model (FSM) is a rather large document that specifies all the required states and optional states, state transition and inputs of the components within the Cryptographic boundary. It includes a state transition diagram and/or a state transition table for every API call that is crypto related.

Some areas such as the Physical Security and EMI/EMC are not applicable to software only modules.

The Operational Environment section details the conditions and systems on which the module will be deployed. For Level 1 validation, the crypto module must use a commercially available general purpose Operating System and the module be installed as executable only code. A FIPS approved authentication technique must be applied to the software; in our case we sign the module binary with RSA or DSA key. The module must protect CSPs from other processes and users. And best of all, the OS must be restricted to single operator mode; more on this later.

For Level 2 validation, however, it is required that all cryptographic software/firmware, keys, and CSPs must be under control of an Operating System rated to EAL-2 to an approved product profile, or an equivalent trusted OS, and that it maintains a controlled access profile (TCSEC, C2, ITSEC, C2/E2, etc).

The Cryptographic Key Management section details how keys are created, accessed, modified, and destroyed. The standard requires that key generation must use a FIPS approved random number generation method such as X9.31 and that all secret key material (CSP) be zeroed as part of the deletion process.

FIPS-140-2 also requires that when establishing a symmetric key, an appropriate size public key and hash algorithm must be used. For example, when wrapping an OpenPGP message encoded with an AES-128 key, you must use an RSA key of least a 3073 bits. This requirement isn’t always practical when using larger keys like AES-256, since that would need a RSA 15360 bit key.

The documentation process also requires detailing design assurance items, such as the software development process, configuration management, distribution, and installation.

FIPS Mode and Self-Tests

While the FIPS-140-2 allows a module to include non-approved algorithms or functionality such as CAST-5 or BlowFish, it can only be invoked outside the FIPS approved mode of operation. The PGPsdk module provides a special FIPS approved mode of operation. The module is defined as powering-up into FIPS mode when the PGPEnableFIPSMode() call is made by the client application. In addition to restrictions set forth by the Security Policy, entering FIPS mode has a number of effects on PGPsdk operations.

The module must perform a series of self-tests upon entering FIPS mode. These tests can also be run on demand. Typically these tests involve running each symmetric crypto algorithm and mode against a series of known answer tests. Non-deterministic public keys algorithms are also tested for pairwise consistency by encrypting a plain-text value with the public key, checking that the cipher-text is not the same as the original plaintext, and then decrypting with the private-key and checking against original plain-text.

While in FIPS mode there are also a few tests which are performed under certain conditions, such as when new public keys are generated or when random numbers are created. Failure of any self test puts the module in error state, and disables all further crypto operations.

One other test is against the module integrity using a built in public key to verify a detached signature of the library binary itself.

The Validation Process

Module validation and testing is facilitated by a Cryptographic Module Testing (CMT) Laboratory. The CMT labs themselves must be accredited by NIST’s Cryptographic Module Validation Program (CMVP). The primary role of the CMT lab is to test the cryptographic module against all applicable requirements specified in FIPS 140-2 and record the results. The module and its documentation undergoes extensive scrutiny by the CMT. For example, one of the tests is known as the “operational test” or “optest,” in which every module API is exercised against a series of procedures known as “Test Evidence.”

In addition to validating the crypto module, the FIPS approved algorithms within it must be also tested for compliance by the Cryptographic Algorithm Validation Program (CMVP). The algorithms are run through a battery of random test vectors by the CMT which must be passed before the enclosing module can be validated.

Once a test report is compiled, the test lab submits a report to NIST for review. At some point NIST assigns the report to a reviewer who could issue questions or comments on the certification report back to the CMT. When all questions are resolved and resubmitted a certificate is issued by NIST. Certificates and validation status are posted on the CMVP website. The time from when the report is submitted to NIST until the certificate is issued varies but is typically anywhere from 3-6 months.

The validation process can be extensive and make take on the order of several months, and validations do need to be updated when the module version number changes. However, if module updates do not involve changes to crypto sections, or are not security relevant changes, the update can be an easy process (approximately 1-2 weeks). If less than 30% of testable requirements change, NIST looks only at the changes.

FIPS-140-2 Practicality

It could be argued that the FIPS-140-2 standard is far from perfect. Functions such as module integrity testing could be better provided by the most modern operating systems. The tamper evidence and role-based authentication requirements of Level 2 are the result of trying to shoehorn guidelines for cryptographic telecommunication equipment and postage meter machines into a software-only crypto library environment. The symmetric key wrapping requirements in some ways weakens message encryption. But the biggest offender is that to properly comply with the standard, a Level 1 module would have to run in single user mode. Is this even possible with modern OS implementations?

One has to keep in mind that the standard is several years old and that it was originally drafted around the PC-AT. But the FIPS process is rigorous and does add a number of useful considerations to the design of crypto modules.

Filed under: Vinnie's Views
Tags: AES-128, Common Criteria, Cryptographic, Cryptographic Algorithm Validation Program, Cryptographic Module Security Policy, Cryptographic Module Testing (CMT) Laboratory, DoD, FIPS 140-2, NIST, PGPsdk
Comments: No Comments

PGP Identity Management: Secure Authentication and Authorization over the Internet
Friday, September 3rd, 2004

Abstract
Access to computer services has conventionally been managed by means of secret passwords and centralized authentication databases. This method dates back to early timeshare systems. Now that applications have shifted to the Internet, it has become clear that the use of passwords is not scalable or secure enough for this medium. As an alternative, this paper discusses ways to implement federated identity management using strong cryptography and the same PGP® key infrastructure that is widely deployed on the Internet today.

Beyond Passwords
The inherent security weakness and management complexities of password-based authentication and centralized authorization databases make such systems inadequate for the real-world requirements of today’s public networks. However, by applying the same proven cryptographic technology used today for securing email, we can construct a robust authentication system with the following goals in mind:

Provide a single sign-on experience in which users only need to remember one password, yet make it less vulnerable to “cracking” (hacking) attempts.
Employ strong user authentication, extendable to multi-factor methods such as tokens or smart cards. The only copy of the authenticating (secret) material is in the possession of the user.
Design such a system so it does not depend on any trusted servers and so that the compromise of any server does not affect the security of other servers or users.
Build on existing and well-accepted infrastructures that scale to fit a very large base of users and servers.
Enable users to sign on to the networks of more than one enterprise securely to conduct transactions.
Authentication with Cryptographic Signatures
Email communications via the Internet face a security challenge similar to network user authentication. Messages traveling through public networks can be eavesdropped or counterfeited without much effort. Yet we have been able to successfully mitigate these risks by using public key cryptography to digitally sign and authenticate email messages.

With public key cryptography, each user generates a pair of mathematically related cryptographic keys. These keys are created in such a way that it is computationally infeasible to derive one key from the other. One of the keys is made publicly available to anyone who wishes to communicate with that user. The other key is kept private and never revealed to anyone else. This private key can be further secured by either placing it in a hardware token, encrypting it to a passphrase, or sometimes both. The holder uses the private key to digitally sign data. This digital signature can later be checked with the matching public key to ensure the data has not been tampered with and that it originated from the holder of the private key.

Because the holder of the private key is the only entity that can create a digital signature that verifies with the corresponding public key, there is a strong association between a user’s identity and the ability to sign with that private key. Thus, a digital signature is strong testimony to the authenticity of the sender.

Cryptographic Challenge-Response
Because the public key functions as a user’s identity in cyberspace, we can apply digital signatures to strongly authenticate users of network services. One way to do this is to challenge the user to sign a randomly generated message from the server. The server then verifies the identity of the user with the public key. This process is illustrated below.

The user initiates network service access.
The server looks up the user’s public key in its authentication database. The server then generates a random challenge string and sends the challenge to the client.
The client digitally signs the challenge string and returns the cryptographic signature to the server. The client also sends a counter-challenge string, which is used to verify the server’s authenticity.
The server then checks the client’s signature, and if successful, grants access. It also signs and returns the client’s counter-challenge.
The use of such cryptographic user authentication offers a number of advantages over password-based systems. For example, if we employ the same key used to sign email, user authentication becomes as strong as the applied cryptographic digital signature algorithm. This approach reduces the need for users to periodically change the password, yet means they only need to remember one passphrase for all servers using this system. In addition, because the user maintains the only secret material in the system, compromising a server’s user database results in only limited damage. All this can be accomplished without the risks associated with passphrase caches or key chains.

PGPuam – Proof of Concept
A public key login system was originally prototyped by the author as PGPuam and later distributed as sample code by Apple Computer in 1998 [PGPUAM]. Consisting of an AppleShare-IP client and server plugin, the system enabled a user to perform two-way strongly authenticated logins to an AppleShare-IP server from a Mac OS client. The cryptographic routines were provided by the PGP® Software Development Kit (SDK) shipped with PGP 6.0. The user interface was an extension of the existing AppleShare login and is illustrated below.

Although entirely functional, the PGPuam sample was never intended to be a shipping product. Rather, it was meant to be a practical demonstration of why public key cryptography should be treated as a core operating system component. Unfortunately in the late 1990s, cryptography was mired in both commercial and political constraints and widespread public key infrastructure (PKI) was slow to solidify. Nevertheless, PGPuam was successful in demonstrating that cryptography could be used for more than encrypting email. (Note that AppleShare-IP was just a convenient test platform. This concept is portable to file servers that support plugin authentication modules such as Apache modules or Windows GINA Authentication DLL.)

Authentication vs. Authorization
Although the PGPuam authentication effectively addresses most password management and single sign-on issues, it does nothing for user authorization. File servers still have to maintain some form of user-file access control database. Managing and maintaining these user authorization databases securely quickly become cumbersome for server administrators when more than a handful of servers are involved.

Consider, for example, what happens when a new user wishes to gain access to a server. The system administrator must create an account and add the user’s name and access information to the appropriate server database. If the user wishes to access a number of servers, this process must be duplicated and kept synchronized on each server. This process is further exacerbated when the servers are owned by different organizations. Conversely, when a user departs from an organization, each of the servers must then be updated to reflect this change. Often, removed users are overlooked and left active on servers managed by different departments, thus creating a security risk.

Although have been a number of attempts to create automated systems to replicate or centralize the authorization databases, such as Kerberos, they all seem to share the following drawbacks:

The authorization server itself must be physically secure and is a critical link in the security chain.
Each server must be in communication with the authorization server to verify user identity and authorizations. This could be an unreasonable requirement for remote sites or devices such as a door badge reader, for example.
The authorization server is an ideal target for denial-of-service attacks because they affect all the servers managed by it.

PGPticket – Secure Federated User Authorization
A number of papers have described ingenious alternatives for distributing network service authorization [BFL] [SPKI]. In particular, the Simple Public Key Infrastructure (SPKI) model introduces a change in how authorization is performed for network services. Instead of maintaining a per-server database of users’ names, passwords, and their corresponding access rights, we can apply digital-signature technology to create an authorization certificate. Think of this certificate as a digital “permission slip,” valid only for a specific user’s key over a certain period of time. The authorization certificate is signed by the organization or a proxy that owns the server and presented by the user upon accessing a restricted service.

One way to encapsulate these certificates is in the form of an OpenPGP standalone signature packet [OPENPGP]. These packets, known as PGPtickets , form the basis of a lightweight but very secure federated authorization protocol [PGPTICKET]. Each PGPticket contains the following fields:

The ISSUER who generates and signs the certificate, represented by a PGP® Key-ID.
The SUBJECT, the principal or set of principals to which the certificate grants its authorization. A combination of KeyID, algorithm ID and key fingerprint is used to represent the subject.
VALIDITY is some combination of dates or online tests specifying the validity period/conditions of the certificate-typically, a creation and expiration date. This field might be useful for a school that wants to allow access to facilities for a limited period such as a term.
AUTHORIZATION is a structured field expressing the authorization this certificate grants to the subject. This data could be represented as SAML or some form of XML.
DELEGATION is a flag that indicates if the subject is allowed to delegate the specified authorization further.
PGPtickets can be issued in or out of band and are uniquely identified by the hash of the ticket packet, known as its Ticket-ID. The issuer verifies the subject’s key information through standard practice, such as key fingerprint. Unless there is a specific requirement to encrypt the signed tickets, they can be returned via cleartext email or even placed on a public website and accessed by the Ticket-ID. The subject can even store the ticket in a database, smart card, or token.

The following illustrates the process of accessing a service with a PGPticket:

The user requests server access from the system admin. The user provides either a copy of his/her public key or makes the key available on a keyserver. The issuer verifies the validity of this key.
The administrator generates the PGPticket with appropriate authorizations and validity information, signing the ticket with the server admin key. The ticket is either posted in a public place or sent by email to the user.
The user retrieves the PGPticket and stores it in a local ticket database.
When the user attempts to access a network service, the client searches its ticket database for the appropriate ticket and sends a copy of it along with the access request.
The server checks the validity of the ticket by verifying the admin signature and expiration date of the ticket. The server then generates a random challenge string and sends the challenge to the client, requesting that the key specified in the ticket sign it.
The client signs and returns the challenge, which is checked by the server and, if successful, access is granted with the authorizations specified in the ticket.
The server only requires a copy of the root issuer’s public key. It does not need to store copies of the subject’s public keys because the key fingerprint is signed into the ticket body. The subject public key can be provided by request from the client and cached for later use. The same is true for delegated tickets. There is no specific requirement for a certifying authority, although its use is certainly not precluded and would make PGPtickets usable for small sites as well as enterprises.

One of the more interesting features of this design is that it enables the servers to function without access to a keyserver, independent of outside influences and resilient to denial-of-service attacks. This approach allows the use of PGPtickets for standalone devices where no network connection is practical, which opens a number of possibilities. PGPtickets can be transported in a token or Bluetooth device, and not only used for such things as Web Service or VPN access but also for restricted door access. In essence, PGPtickets could extend the usefulness of the PGP® PKI to the physical world.

PGPcoupon – Building on XML Web Services
Other interesting possibilities occur when you consider that PGPticket piggybacks on the flexibility of the PGP® key infrastructure. Consider a system that produced tickets automatically through some pay-per-use service and combine that with anonymous keys. Or what about using the key-splitting features to create a ticket that needs a certain amount of shares for service access?

Another possibility is to mix the technologies of PGPticket and XML object Web Services. A client could post a Web request for a proposal whereby vendors could reply with a PGP-signed coupon that would be honored by various distributors for a given period.

For example, imagine a school wants to purchase a number of books; various vendors compete for the order and send replies. In the replies is a 20% off PGPcoupon that Amazon or BN.com would honor. The client could then present this coupon upon purchase and have the transaction processed automatically.

Conclusion
I have outlined a number of alternate uses for PGP® technology that go far past email encryption. Most of these designs have been around for a number of years, but were untapped because of political or commercial restraints and, at times, lack of vision. Fortunately, the environment has changed and cryptographic technology can be used to solve a number of real-world identity management problems today.

References
[OPENPGP]
Callas, J., Donnerhacke, L., Finney, H., Thayer, R. “OpenPGP Message Format.” RFC 2440, November 1998

[SPKI]
Ellison, C. “SPKI Requirements.” RFC 2692, September 1999

Ellison, C., Frantz, B., Lampson, B., Rivest, R. “SPKI Certificate Theory.” RFC 2693, September 1999

[BFL]
Blaze, M., Feigenbaum, J., and Lacy, J. “Decentralized Trust Management.” Proceedings 1996 IEEE Symposium on Security and Privacy.

[PGPTICKET]
Moscaritolo, V. “PGPticket – A Secure Authorization Protocol.” Mac-Crypto Workshop, October 1998

Moscaritolo, V., Mione, A. draft-ietf-pgpticket-moscaritolo-mione-02.txt

[PGPUAM]
Moscaritolo, V. “PGPuam – Public Key Authentication for AppleShare-IP.” Mac-Crypto Workshop, October 1998

Filed under: Vinnie's Views

Comments: No Comments