PGP Blogs

Bryan Gillson – Senior Director Product Management

Encryption has always been about trust. Questions about who you trust and who you distrust, are critical to determining whether (and how) to encrypt your data. Of course, trust-related questions go beyond just specific threats and extend directly to the selection of an encryption vendor.

This is why, since its founding, PGP Corporation has made its source code publicly available for cryptographic review. We feel that the ability for the public to study our source code and personally confirm the quality, validity, and security of our cryptographic implementations has been a key reason for the trust placed in PGP Corporation and our products. This belief has been reinforced by many customers across the spectrum: corporate, individual, educational, and government.

Now that PGP Corporation is a part of Symantec, many customers have asked whether we will continue to publish our source code. In other words, does Symantec share this commitment to security and trust? The short answer is “Yes.” Symantec’s management team believes as we do: confidence in cryptographic implementations is critical to securing data against the latest  sophisticated threats coming from organized criminals and nation states.

The longer answer is slightly more complex.

As with all U.S. companies selling strong encryption software, Symantec must comply with  U.S. federal export regulations. These regulations require the filing of detailed information about ciphers, algorithms, functionality, and implementations. After review by the appropriate federal agencies, the products are assigned a classification and various ID numbers (you can see our existing export information here: http://www.pgp.com/products/export_compliance.html).

As part of the acquisition by Symantec, all of PGP Corporation’s products must be reclassified – and this includes the source code we make available.  Standard process would involve removing our source code from our download section during the period of review.  However, Symantec understands the potential impact this would have on our customers’ trust, and the questions it could raise.

Consequently, during this review period we have reached a compromise under which we will  allow download and review of our source code only from within the United States. This compromise allows us to continue with this important policy while also satisfying the strict regulations under which encryption vendors must operate.

Transparency is another element of trust, so we wanted to be sure to publicly communicate this change and the rationale. While it may cause some frustration for our many users outside of the U.S., we hope you understand. We expect this will be temporary and will update our blog and source code download pages when the review and reclassification is complete.

Brian Tokuyoshi – Senior Product Marketing Manager

I recently attended the 2010 IEEE Key Management Summit, an event that brought together the leading industry pundits talking about the topic of key management. I had a number of interesting discussions with vendors, researchers and customers throughout the conference. In this blog, I’ll summarize some of the things that I saw and offer up a couple of opinions of my own.

The IEEE Key Management Summit was held the first week of May at North Shore Lake Tahoe, Nevada. This event attracts a technical audience, with heavy participation from the leadership of the standards group such as OASIS KMIP, IEEE 1619.3, and IETF KeyProv.

This is the second such conference, the first of which was held in back in 2008. That inaugural event had a number of healthy and loud discussions, where there were clearly differences in philosophies between the pragmatists (“This is a problem that exists now, we need to do something immediately”) and the academics (“We acknowledge there is a problem, but we can’t rush the solution and we need time to fully explore the ramifications of each approach”). The pragmatists tend to believe that a solution comes about by taking action first and making iterative improvements to fix any deficiencies. The academics believe that a good solution can withstand the crucible of public scrutiny through a review process which leads to a better solution done right the first time. As such, the discussion was both insightful and sometimes inflammatory, but always interesting.

In the time that’s passed since the first event, the market has changed. Some vendors in the key management space changed ownership. The KMIP standard emerged and is on track towards a public review. And while there are still many key management issues that need to be solved, the event had more camaraderie and a sense of working towards common goals.

What’s unchanged is that the problem hasn’t gone away. Everyone in the room still agrees that there’s pressing need to protect data and that many enterprises do not have proper tools to manage the keys in a large heterogeneous environment.

The question, though, lies on where to start and what needs to be done to solve the issue. Some believe that the most important issue is to address key management for storage, since it’s a mature market that requires solutions now. Some believe that applications that need keys is the highest priority, since this work is ongoing right now as many companies struggle to bolt on encryption to decades of existing data and code. And there’s some that think that we might have made a big mistake going down the road of using public key in the first place, and it might be better to start over again.

I believe though that no matter where the technology and market goes, there are some basics that need to be addressed.  First, any true key management platform needs to be able to address the problem that organizations have right now, which means that it must be able to handle asymmetric and symmetric keys. We should be open to new approaches, but being able to tackle the tough problems that organizations face today must be the foundation. That’s really what enterprise key management is all about – it’s being inclusive of the variants that may exist and bringing tools to help manage it all. Solutions in this space need to address existing keys for the foreseeable future.

Second, I think the various discussions going on now about how to link a key repository to an application are all equally valid, because that’s really an area that’s been ignored for too long. It’s similar to the broadband issues of the ’90s – it doesn’t matter how good your infrastructure is if you can’t take care of that last mile.

The approach that PGP Corporation took was to first look at how to build the best key management environment first, and design different ways to handle the integration to account for emerging standards. We had a good head start, since we already managed a large number of keys for the PGP application stack, such as our PGP Whole Disk Encryption and PGP Desktop Email products. Using that base, we created general purpose key containers to help manage and tag the keys appropriately for different use cases.

Next, we created various ways to perform application integration through a general purpose agent, an API and an SDK. We thought that made sense, and we needed that in order to handle the different types of integration that our customers needed. In addition, we created an adaptable interface that allows us to add support for various standards as they solidify, allowing us to support different protocols in the future.

At the IEEE Key Management Summit, Landon Noll of Cisco Systems gave an excellent talk about the state of key management, and he has a lot of insightful thoughts about the different problems with application integration.  He points out the issues far more eloquently than I can, and it’s definitely worth your time to listen to his talk about when to use a particular approach and its ramifications.

In general, I’m pleased to see the direction where key management is going, and based on the feedback from our customer base, I think that we made the right decisions on the approaches we took to build PGP Key Management Server. We think that the work that is going on with the key management community will be important for broader adoption of these technologies. I think that we’ve made a lot of progress as an industry as well, because there are a number of issues that we need to work on together to ultimately make encryption products easier to manage.

With all of the progress that’s been made in the last two years, I simply can’t wait to see where the market be when it’s time for the next IEEE Key Management Summit.

The full archive (with slides and video) for the 2010 IEEE Key Management Summit is available from this link.

To get more technical detail on the PGP Key Management Server, look for the June 15^th webcast available on BrightTalk.

Brian Tokuyoshi – Senior Product Marketing Manager

Putting together a good data protection strategy shouldn’t depend on whether or not your security vendor  chooses to support it. However, based on the adoption of the Apple Macintosh in the enterprise, a lot of IT organizations are getting caught off guard. They’re finding that the vendor they chose to protect their Windows data doesn’t offer any solutions to address Mac OS X users, thus creating a gap in their data protection strategy for an important and growing segment of their user population.

The rise in the use of Mac OS X in business is attributable to a number of factors, including grass roots adoption by individual users, growing consumerization corporate IT, and the acquisition of new companies that have an existing Mac installed base. It’s not practical to just leave these laptops unprotected, and it’s  an equally bad idea to use a separate product with a different set of administration tools.

PGP Corporation’s product line includes support for both Windows and Mac OS X platforms, and organizations can mix & match while using the same administrative tools. One of the popular configurations that many users ask us about is how to set up PGP Desktop Email with one of their existing email accounts. In particular, Google Gmail is one of the most popular messaging platforms, and it does support access from a mail client via the POP and IMAP protocols. In this blog entry, I  provide step-by-step instructions on how to get PGP Desktop Email working with Gmail. These instructions explain the process using a Mac Book Pro with Mac OS X version 10.5.8, Apple Mail 3.6, and PGP Desktop 10.0.2

Note that deploying PGP Desktop Email together with PGP Universal Server will dramatically reduce the number of steps listed below. This configuration guide is to help users with standalone configurations. This process should take about 10 minutes to do.

Step 1: Setting up POP Access in Gmail

The first step is simple – the ability to access email via POP is not turned on in Gmail by default. Log into your Gmail account, click the Forwarding and POP/IMAP button, and choose one of the options to enable POP in the POP Download: options.

Step 2: Setting up PGP Desktop Email on your Macintosh

This step simply involves installing the PGP Desktop client. I’ll assume that you didn’t have any problems getting the installer going  and I’ll jump ahead to explain how the wizard sets up a PGP key. (In order to clarify the terminology, a PGP key is a structure that can contain other keys. So a PGP key actually contains a public key, a private key, and possibly additional symmetric and asymmetric keys as well depending on how the PGP key has been set up).

The first screen simply asks the user whether or not they have an existing PGP key. It’s to determine whether the wizard should take the user through the process of creating a new PGP key, or to import an existing one. Let’s create a new key for this tutorial by selecting “I am a new user.”

The next step explains where the keyrings live on your local file system. When you’re done creating your PGP key, it’s important to backup your keyring in order to avoid the problem of a lost or damaged key. This is especially important if you are not using PGP Universal Server to provide the administrative services for key recovery.

The wizard then displays some tutorial information about what’s going on when creating a new PGP key.

When creating a PGP key, the key must be linked to some identity that declares the owner. I’m making this key for a Gmail account and I enter that user’s name and email address in the dialog.

In order to protect the private key, a user must enter a passphrase to unlock it. This step prevents unauthorized usage of the private key in the event that an unauthorized party obtains it.

PGP Desktop Email presents a summary of the characteristics of the PGP Key being created.

The wizard provides details about the key generation process and lets the user know that it’s complete.

The PGP Global Directory is a hosted service that allows users to look up the public key of another user.  The wizard walks users through the steps to get your newly created public key published so that others may send you encrypted email through this service. Note that using the PGP Global Directory is optional, and there are other methods to exchange a public key with another party without using this service.

That concludes the PGP Key creation wizard. If you want to see your key in the PGP Global Directory, open a web browser and visit http://keyserver.pgp.com

When searching for a key, be mindful of the search options to make sure you’re searching through the correct field, and that you understand how the modifiers affect a search. In this screen, we’ve successfully located our user in the global directory. There’s an option to download the key, thus permitting encrypted communication with the user.

Step 3: Setting up Apple Mail 3.6

Both Apple Mail and PGP Desktop Email have wizards that help simplify the setup process. However, there are some peculiarities with Gmail that confuses both wizards, so it’s better to do setup manually. (For the gory details, Apple Mail attempts to enable SSL in the wizard and doesn’t provide an option to override the setting unless it’s manually configured. The wizard also gets confused because Gmail reroutes requests from gmail.com to  the 1e100.net domain, which makes it look like it’s setting up the wrong email account. On top of all of this, Gmail uses its smtp.gma)

First, let’s setup Apple Mail, and make sure that it’s working properly with Gmail.  We’ll first disable PGP Desktop Email so that we don’t confuse the PGP wizard during the configuration process. Let’s first quit PGP Desktop Tray, which is a background service that handles communication with desktop applications.

To quit PGP Desktop Tray, you’ll need to hold down the OPTION key while clicking the PGP lock icon in the upper right corner of the screen. This will enable the Quit option to appear.  If you do not hold down the OPTION key, the Quit option will not show up. This feature prevents people from accidentally quitting the PGP Desktop Tray. PGP Desktop Tray should be running all the time under normal circumstances, but because we’ll be doing manual configuration, go ahead and hold down the OPTION key to activate the Quit option.

Launch Apple Mail and it will start the wizard to create a new account.

After clicking Continue, Gmail should be working properly with Apple Mail.  Test it out by creating an email and testing send/receive.

Now let’s reconfigure the account so that it will work with PGP Desktop Email. We need to set up the account so that it can use PGP Desktop Email as a local mail proxy for Apple Mail. What this means is that PGP Desktop Email will make the actual connection to the Gmail servers, and takes care of the email encryption/decryption automatically as the mail stream passes.

In order to do this, we’ll need to prevent Apple Mail from making an SSL connection for both POP and SMTP.

In Apple Mail, under Mail->Preferences, get ready to edit your account information. The first thing that we’ll do is reconfigure the SMTP connection.  Click the arrow buttons that appear in the Outgoing Mail Server next to Gmail SMTP and click Edit Server List.

Under the Advanced tab, there is a check box next to “Use Secure Sockets Layer (SSL)”.  Make sure that’s disabled and click OK.

Next, go back to your account and click the Advanced tab in the upper right. This will bring up the “Use SSL” option for the POP account. Uncheck “Use SSL”, which will change the port automatically from 995 to 110.  Click Save.

After you saved your configuration, quit Apple Mail so that the wizard doesn’t start up during the steps in the next section.

We’re all done, and now we’re ready for the final step.

Step #4 – Setting up PGP Desktop Email

Make sure that Apple Mail is not running, because otherwise it will trigger the PGP Desktop Email wizard. We want to set this up manually instead.

Launch PGP Desktop Email and go to PGP Messaging.  Click the button to Create New Service.

Now we’ll enter the information that helps PGP Desktop Email understand how to make the connection to Gmail. The configuration should be relatively straightforward. Note, you’ll want to make sure that you set the default key to the key that you just created during the setup process, so that PGP Desktop Email knows that this key belongs with this account.

After configuring PGP Desktop Email, you’re  ready to start testing.

Step #5 – Testing it out

Launch Apple Email, and create a new message.  A good way to test that the service is operating correctly is to send a message to yourself.

After creating a test message and sending the mail, PGP Notifier will show the state of the encryption process. Since we need to unlock the private key (again, in order to prevent authorized use of the private key in case of theft), there’s a prompt to enter the passphrase for the key. The message will be encrypted and signed and sent along its way.

After waiting a moment, check your email and you’ll see it arrive. Open the message and you can see that the message contains an annotation that indicates that the original message had a digital signature and was encrypted.

You should be up and running and enjoying secure email with your Macintosh. That wraps up the tutorial on using Apple Mail with Gmail and PGP Desktop Email. Feel free to drop a message in the comments section if you need any clarification on any of the steps listed above.

PGP recently held a webcast on key management, where there were several questions that we didn’t have enough time to answer during the broadcast. In this blog entry, you’ll find the answers to those questions.

• Replay in English
• Replay in German

We didn’t have time to answer all the questions during the webcast, but I wanted to circle back and provide you with a detailed answer.

Q: Do you need both PGP Universal Server and PGP Key Management Server?  Or does PGP Key Management Server replace PGP Universal Server?

A: PGP Key Management Server is a new product based on some of the components of PGP Universal Server.  PGP Universal Server is for the management and administration of keys used with PGP applications. A company would use PGP Key Management Server for broader management capabilities such as the administration of keys and certificates with custom applications and 3^rd party software and hardware packages. PGP Key Management Server and PGP Universal Server may coexist in the same server instance, however.

Q: What are some of the things that make PGP Key Management Server different than PGP Universal Server?

A: The design of PGP Key Management Server centers on the ability to manage a broad set of keys. For example, from the administrative perspective, organizations typically manage keys by the application that created them, thus creating a fragmented administrative model.  You manage one key with the admin console of application 1, and you manage the second key from application 2, even if both keys belong to the same user. PGP Key Management Server organizes keys by the consumer of the key material, thus making it easier to apply policy around that key.

The second major difference is the approach we took to add support for the various different ways to integrate an application to PGP Key Management Server (see the question below on Agent/SDK/API for an in depth explanation).

The third major area that was redone was the API interface, which was set up in an way to handle extendibility for easier integration today and support for emerging standards, such as OASIS KMIP, down the road.

Q: What about S/MIME?

A:  PGP Key Management Server can generate X.509 certificates suitable for use with S/MIME.

Q: What about SSL?

A: PGP Key Management Server can generate X.509 certificates for use with SSL. One thing to keep in mind about SSL is that there are generally two types of uses for SSL. One is to make internal communications more secure by protecting server to server network traffic. The second is to provide server identification in order to establish a secure connection over an external untrusted network. The second use case requires a trust chain back to a pre-trusted root certificate, which essentially means that a web browser needs to be able to identify where the certificate came from. Users who need to use SSL in an externally facing network environment may be interested in learning more about PGP TrustCenter, which provides the trust chain needed to secure external network traffic.

Q: Where can I find more about Key Management?

A: Ramon Krikken, an analyst at Burton Group / Gartner is a subject matter expert in the enterprise key management space, and produces excellent in-depth reports. Burton Group provides its reports on a subscription basis only, so your organization will need to be a member of Burton Group in order to read that material.

Jon Oltsik is an analyst at Enterprise Strategy Group and covers key management on a regular basis in his writing and on his blog hosted on Network World.

IEEE recently hosted “Key Management Summit 2010”, and the website has video of the speakers and the slides available on its website.

Q: How do you provide keys to applications?

A: There’s basically three primary methods for getting a key to and from a server, and that’s through either an agent, an API, or an SDK.

The agent approach relies on a piece of software on the client to handle the interaction with the key server.  The agent must first authenticate to the key server in order to establish what that particular agent may do. Once connected, the agent can then communicate to the server and perform key operations such as request a key from the server or push a key to the server.

PGP has a general purpose agent available that performs these functions, and it’s available on over 35 different operating system variants, including Microsoft Windows, Apple Mac OSX and various Unix / Linux variants.

The API approach pushes the complexity towards the server, but the application needs to know how to talk the API. Organizations that build their own custom software can take advantage of the API approach. With the adoption of mature open standards in the key management space, the API approach will become more mainstream.

The SDK approach is a middle ground between the agent and the API approach.  Using an SDK, an organization can build the functions they need in order to integrate with a key server and provides tighter integration than the agent approach, but it does require familiarity with the process to integrate with the application code.

All three approaches are available with the PGP Key Management Server.

PGP NetShare provides transparent encryption for files in designated folders.  Transparent encryption means that the user doesn’t have to do anything to protect the file other than unlock their private key when they first log into Windows. There’s no right-clicking files to bring up the context menu, and no archive passwords to remember. I simply double click on files that I want to work on, and it’s automatically decrypted.  When I save a file, it’s automatically encrypted. I can still copy & paste the files in the same manner that I normally follow, without any changes to my work process.

Typically, an organization uses PGP NetShare for collaboration, enabling an organization to set up workgroups with network shared folders that remain safe from snooping even if accessed by a curious system administrator or copied to a backup tape.

However, what’s not so widely known is that there are lots of uses for PGP NetShare even when you’re not doing any collaboration.  It’s transparency and ease of use that makes NetShare convenient for even the single user. I’ll illustrate a couple of scenarios.

The first scenario is to use a network drive as a virtually private hard drive. For instance, I have a relatively small hard drive on my laptop, and I keep the large, bulky work files like artwork and scans on a network drive. It’s useful for me because I don’t have to take care of doing any backups for files on the network drive because the system administrator does it for me. But what about keeping the data protected?

I use PGP NetShare to encrypt the data, even though this folder isn’t used for any collaboration. I can take advantage of having a large network drive without any of the headaches of managing the files or protecting the data. The blue lock on top of the drive icon shows that NetShare is operating, and I don’t have to worry about anyone else inappropriately accessing my data.

A second non-collaborative use for NetShare is to add encryption functions to applications that don’t have encryption capabilities. For instance, SyncBack Freeware from 2BrightSparks is a fantastic backup solution, but it doesn’t have the ability to create an encrypted backup. That’s not a problem when I’m using NetShare. I simply create a NetShare folder (in my case, I chose to use a folder mounted on my network drive), and set that as the destination in SyncBack. When I run my backups, the files are automatically encrypted, thus ensuring that my backup data stays safe.

An additional benefit for using NetShare to handle my encryption is that I now have a consistent method for accessing and recovering the data, even though I use different programs to create the data in the first place. In the past, I would have to set a passphrase with each application that created the file, such as using a passphrase for creating a backup, set a passphrase when saving my office documents, and choosing a passphrase for an encrypted zip. By the time I actually use the data, I may have forgotten the passphrase, which leads to data loss of the information that I was trying to protect in the first place. I remember one time in the past when I needed to access an encrypted spreadsheet that contained important pricing details, and forgot the passphrase which meant I had to recreate the document from scratch.

With PGP NetShare, whether it’s accessing data from my shared drive, or restoring a file from a backup, I simply use the file the way I normally would. If I need to work on it, I double click the file and it opens without any prompts for passphrases. If I need to move it, I just drag and drop it and NetShare takes care of the encryption.

It’s this aspect of PGP NetShare, the transparent encryption, that makes data protection effortless and useful for even the single user. And ultimately, by making it easier on the user, it’s more likely that users can protected more data and avoid the accidents and attacks that lead to data loss.

Brendon J. Wilson – Director of Marketing, PGP TrustCenter

Last week, we held a webcast on Simplifying SSL Certificate Management.  Here’s a link to the replay [registration required]. As this was the first web cast for the new PGP TrustCenter Division of PGP Corporation, there were a wide variety of enthusiastic questions…so many, in fact, that we couldn’t answer them all in the time available. I took a few minutes to summarize the questions and post the answers below.

Q: You mentioned that PGP TrustCenter’s data center is accredited by a number of security standards – which ones? Do you have SAS-70?

A: PGP TrustCenter’s data center is accredited according to ETSI (a European equivalent to WebTrust), Safe BIO-Pharma, IdenTrust, and complies with the requirements of the German Digital Signatures Act. A complete list of accreditations can be viewed here.

PGP TrustCenter is accredited according to ETSI, an accreditation that more specific to the operation of a certificate authority than SAS-70.

Q: Once an SSL certificate is discovered and collected into the system, can its lifecycle be managed regardless of the CA that issued it? Can the solution manage internal SSL from our own CA?

A: TC ID Store allows you to import SSL certificates, regardless of which CA issued the certificate. In the case of imported third-party SSL certificates, this management is limited to providing a unified view of the certificates in the organization; it is not possible to issue new certificates that are tied to the third-party certificate authority, or revoke the third-party certificate.  Importing certificates provides an easy way for you to gain a complete picture of the certificates in use; once you have that information, new certificates can be issued from TC ID Store to replace the old third-party certificates as they expire.

If you already run an internal CA of your own and want to simply add the ability to issue publicly-trusted SSL certificates (or other types of digital certificates) PGP TrustCenter also offers a RootSigning service. By signing your internal CA’s root certificate with a globally trusted root, your CA can issue globally trusted certificates. Depending on your infrastructure and the number of SSL certificates you wish to issue, this may be an appropriate alternative.

Q: Can the SSL Certificate Discovery Tool search for SSL certificates on IBM AIX systems running WebSphere?

A: Yes. In fact, the SSL Certificate Discovery Tool can find SSL certificates regardless of which platform or web application server you’re using to deliver a secure web site. The tool attempts active SSL connections with each domain name, IP address, or set of domain names or IP addresses that you enter into the tool. As long as the service implements the SSL protocol and is available on port 443, the tool will make a connection and gather the SSL certificate used to protect the connection.

Q: When we buy certificates using TC ID Store, do the funds expire? Can we buy as needed for any extended period of time?

A: TC ID Store uses a deposit model: you deposit funds in the system, and certificates you purchase are charged against the deposited funds. The more funds you deposit, the lower the per-certificate costs. Deposited funds expire after two years; however, if you deposit additional funds before the two years expire, the deposited funds “roll over”.  Your deposited funds don’t expire for another two years from the date of the newly deposited funds, subject to some minor restrictions.

Q: What type of user certificate provisioning can a company use to have their end users request and deliver client certificates?

A: If you are interested in automatically deploying client certificates to enable email encryption, client authentication, or other applications, you might be interested in TC EID QuickStart and the option TC Enterprise ID AutoEnrollment Server. TC EID QuickStart is very similar to TC ID Store, except that pricing is on a per-user basis rather than a per-certificate basis. The optional TC EID AutoEnrollment Server allows your organization to use your existing Microsoft Windows clients and Active Directory to automatically provision client certificates. From the client’s perspective, the Windows client requests certificates from TC EID QuickStart in accordance with policy set in Active Directory and installs the certificates automatically.

Q: What alerting methods does TC ID Store provide? Will TC ID Store send reminders ahead of the expiration and is this reminder window user-configurable?

A: TC ID Store uses email-based altering to notify an administrator that a certificate is about to expire. By default, these notifications are issued 30, and 14 days prior to the expiration date, in addition to an alert sent on the day of expiration. You can set the notification window, and you can also customize the templates that are sent to the users upon notification.

Q: Can one track Domain Names as well with your system?

A: Although TC ID Store and the SSL Certificate Discovery Tool track the domains associated with individual SSL certificates, the system itself is focused on managing certificates, not domains.

Q: Does the system enable the user PKCS-12 export with both private and public keys?

A: In general, the private keys for an SSL certificate are held on the system that generated them (usually the web server). TC ID Store only signs the public key to assert that the public key should be trusted, and has no knowledge of the private key. In the case of client certificates used for email encryption and digitally signing, TC ID Store can provide a PKCS-12 download for recoverable certificates generated by the system.

Q: Can you encrypt Word, Excel, or PDF documents with these certificates and enable external users to decrypt them without PGP software?

A: This is actually a feature of a different product line than PGP TrustCenter. PGP TrustCenter issues certificates that you can use to digitally sign these types of documents, but to not encrypt the documents themselves. If you’re looking for a solution to send an encrypted file to a user without PGP software, you might consider the Self-Decrypting-Archive feature of PGP Whole Disk Encryption or PGP Portable.

Q: If we have SSL on SQL or LDAP which does not communicate on port 443, can the SSL Certificate Discovery Tool identify those SSL certificates as well?

A: The current release of the SSL Certificate Discovery Tool is optimized for discovery SSL certificates used for securing HTTP. We are aware of customers that would like to expand their ability to monitor across other types of SSL-secured services, and are in the process of expanding the SSL Certificate Discovery Tool’s capabilities.

Q: Which Smart Cards are supported?

A: In cases where TC ID Store is used to sign digital certificates used for email encryption and digital signing, smart cards may be used to generate and store keys and certificates. In general, TC ID Store supports all smart cards supported by the respective client operating system.

Q: Does this solution help identify internal sites that are NOT using SSL or are passing credentials in the clear?

A: The SSL Certificate Discovery Tool included with TC ID Store is specifically designed to identify services that are already protected with SSL, with the purpose of brings those certificates under a single management solution.

Andrew Klein – Senior Product Marketing Manager

Thanks to everyone who attended the “A day in the life of a file” web cast, recently.  If you missed the web cast, here’s a link to the replay [registration required].  As always, there were many great questions covering a wide range of topics.  The questions and answers are summarized below.

Q:   Does PGP® Mobile support Android and iPhone devices?  If not, when?

A: PGP Mobile is available for Windows Mobile devices. We do receive a number of requests to add support for new devices based on Google Android and Apple iPhone platforms, and we are currently evaluating how support for those devices may fit on our roadmap.

Q:   What about the concept of “whole disk encryption” for smart phones?  For example, encrypting to protect web browser cache files on a smart phone?

A: Many mobile devices have built-in services to protect the memory cards and internal memory of the device, so it would be counterproductive to add a whole disk-like encryption features to these devices. The goal of PGP Mobile is to add data layer encryption to complement existing security measures so that the protection extends beyond the device, in order to protect use cases where an unauthorized user may have access to an unlocked device, or when the data moves on the network beyond the phone.

Q:   How do you support external email use cases, for example, sending a protected file to someone outside of our company who doesn’t have PGP software?  What if I want them to be able to edit the file and send it back while it is still protected?

A: If you use PGP® Web Messenger, you can send an email and attachment to a recipient who logs into the mail service to receive the file.  After reading the message and working on the attachment, the recipient can reply to the email and attach the edited file in order to securely send the new file back.

Q:   What is the difference between PGP® Portable and a thumb-drive encrypted with WDE?

A: Both PGP Portable and PGP® Whole Disk Encryption can be used to encrypt USB drives. Additionally, PGP Portable can be used to encrypt data on CDs/DVDs, and can be shared with users who do not have any PGP software. Here is a table which outlines the different USB encryption options available.

Q:  Can a USB drive be encrypted using PGP Portable even though the host machine is not encrypted with PGP Whole Disk Encryption?

A:   Yes.  Learn more about PGP Portable here.

Q:   I understand that files transferred from a PGP Portable protected device to an unencrypted system are no longer encrypted.  What are suggestions for protecting files needing to be shared with third parties?

A: Although PGP Portable cannot control what an authorized user does with data on a USB drive, the benefit of PGP Portable is that any file editing can be done in-place on the device itself. It is always recommended users view and edit files on the USB drive itself, thus minimizing potential points of failure.  Another possibility is to use PGP® NetShare which is designed to protect shared files.

Q:  Where can I find additional information about the Massachusetts law on data privacy protection that was recently passed?

A:   Start by viewing the PGP web cast MA Data Protection Law: Implementing a Compliance Solution (registration required).

Q:  Is Windows 2008 Server supported for PGP NetShare?

A:   PGP NetShare is a client-based product.  Here is a list of the clients supported.  Files protected by PGP NetShare can be stored on Windows systems which support SMB and CIFS storage, which includes Windows 2008 Server.

Q:  What are the systems supported by PGP Universal™ Server?

A:   There are several hardware and virtualization configurations certified by PGP Corporation which support PGP Universal Server.

Q:  For email encryption, does the email client matter?  If so, is Outlook 2007 supported?

A:   For PGP® Desktop Email a wide range of email clients are supported, including Outlook 2007.  For PGP Universal™ Gateway Server, a wide range of the client and servers are supported.

Q:   Several people asked about the pending Symantec™ acquisition of PGP® Corporation.

A:   Symantec and PGP Corporation understand and respect your concerns.  Most questions can be answered here on the Symantec web site.   If you have any additional questions, please contact your PGP Sales representative.

Brendon J. Wilson – Director of Marketing, PGP TrustCenter Division

Last year, online shoppers spent over $150B in online transactions in the US alone – it wasn’t long ago that the lack of transaction security would have made these revenues inconceivable. Today, the security provided by the Secure Sockets Layer (SSL) protocol not only enables organizations to collect payments on the web, but also to securely communicate sensitive business information to partners, and to deliver internal network resources to remote workers.

As the global recession continues, SSL provides organizations a way to thrive despite the financial downturn by enabling businesses to expand market reach, to streamline costs, to tap far-flung resources, and to explore new revenue opportunities. Tapping these opportunities requires SSL certificates from trusted certificate authorities, such as PGP Corporation’s new PGP TrustCenter division, to enable transparent and secure communications. However, the increased revenues and effortless secure communications promised by SSL come with several hidden costs when not managed properly:

• Certificate costs: When facing tight deployment deadlines, many organizations choose to make a quick “one-off” certificate purchase. However, purchasing individual certificates is one of the most expensive ways to buy SSL certificates, with an individual certificate purchased via a retail certificate authority costing up to 60% more than those purchased in bulk.
• Management and compliance overhead: Maintaining a heterogeneous population of SSL certificates increases the effort required to procure and manage SSL solutions. Administrators duplicate efforts to obtain certificates and negotiate multiple procurement systems. Without a unified view of certificates in use, administrators also have to expend additional time to ensure compliance with security mandates – or risk fines, data breaches, or loss of the right to operate.
• Service interruptions: According to Netcraft, almost 10% of SSL certificates on public-facing servers are expired at any one time. In many organizations, the individual who purchases a certificate may not be with the company when that certificate finally expires. This can potentially cause costly downtime to critical services for partners and employees, and lost customer revenues. In environments subject to regulations, such as PCI, an outage can also throw an organization into non-compliance, resulting in fines, or exposure of sensitive information.
• Opportunity costs: When an organization wants to scale a service that relies on SSL, it may face unanticipated delays in procuring additional certificates. In the simple case, the organization may not have anticipated the expenditure, and must wait for budget approval. In cases where the service in question requires a high-security certificate, such as an Extended Validation (EV) SSL certificate, the Certificate Authority’s process to confirm the organization’s identity will prolong the procurement process. Unanticipated delays not only cost the organization time, but also revenues, competitive advantage, and the flexibility required to adapt quickly to a changing market.

To combat these hidden costs, organizations need to adopt a more strategic approach to procuring their SSL certificates. To do this, organizations need a certificate management solution that enables them to:

1. Inventory certificates: The first step to combat these hidden costs is to identify all of the certificates in use within an organization. An enterprise-ready certificate management solution can identify SSL certificates in use, regardless of the Certificate Authority responsible for issuing the original certificate. Inventorying certificates allows an administrator to not only identify certificates used by both the organization’s public and internal servers, but also to identify expired, obsolete, or improperly installed certificates.
2. Consolidate certificate management: A centralized certificate management solution allows organizations to avoid the time and effort overhead associated with managing certificates obtained from a variety of providers. Using a single console to procure and manage certificates not only eliminates this costly overhead, but also enables an organization to purchase certificates in bulk at significant discounts. Advanced certificate management solutions can also pre-vet an organization to streamline the procurement process and reduce the time required to obtain a high-security certificate.
3. Delegate certificate administration: Consolidating certificate procurement shouldn’t require the responsibility for managing certificates to fall to a single administrator. Instead, a mature certificate management solution allows the organization to separate administrative duties, and delegate procurement, renewal, revocation, and other certificate management tasks to match the organization’s existing resources and processes.
4. Monitor ongoing usage: Detailed reporting is a necessity to enable an organization to maintain the protection provided by SSL certificates. Not only does ongoing reporting allow an organization to avoid unexpected certificate expiration, it also allows the organization to monitor the state of deployment and plan annual budget allocations.
5. Report on compliance: In addition to preventing an outage, an organization needs to be able to accurately demonstrate the state of protection it has put in place. Centralizing and consolidating certificate management allows an organization to easily generate reports to support regular audit compliance activities.

For organizations working to protect their data, their customers, and their businesses, the security provided by SSL is only the starting point – visionary enterprises will consider the need to protect other data and applications. To do this, organizations should seek solutions that allow them to unify management of certificates and encryption keys used across their organization to secure and authenticate documents and email communications, or even protect access to network resources. Centralized management will not only reduce the costs of deploying these security solutions, but also the complexity of managing and maintaining after deployment.

Andrew Klein – Senior Product Marketing Manager

According to the folks at Privacy Rights Clearinghouse, since 2005 there have been over a thousand data breaches leading to over 320 million compromised records in the United States alone.  These records contained personal, financial and corporate information – none of which was encrypted.

The term “record” might imply a database record, but a majority of the breached records were not stored in a database, but instead were stored in “files” such as spreadsheets, documents and log files.  These files were stored on laptops, desktops, CDs and USB drives, which were stolen, lost or compromised. Some were files transferred in-the-clear over unprotected networks.  There were also breaches which occurred when personal financial information was posted on a web site, Social Security Account Numbers were printed on envelopes, and credit card numbers were faxed to Congress.  Such physical (mental?) errors were thankfully a minority of the cases.

Encryption technology can be used to protect individual systems such as laptops and devices such as USB drives.   But what about protecting files on a file server where multiple people share a given file?  Using file permissions (per user read and write) to protect the file doesn’t protect the contents of the file itself, providing little protection if the file system is compromised.   Even the simple act of dragging a file to the wrong folder, a public folder perhaps, increases the risk of data loss.  In short, the file needs to be encrypted, but the encryption of the file must allow multiple people to share it without getting in the way of the collaboration process and protect it even if it is moved or copied elsewhere.

How about if the person who owns the file is able to encrypt it and also specify who can use that file once it’s encrypted?  For files on a server, multiple people could access and share the file as allowed by the owner, but to everyone else the file is encrypted.  This is what PGP NetShare does.  The file owner, who could be the IT administrator or someone else, decides which shared files to encrypt and who can use them.  To the allowed users, the experience of using the file doesn’t change, except for the little lock icon on the file.  In addition, the encryption protection stays with the file.  This way, if the file is moved to another location, it is still encrypted.  So if the file is ever stolen, lost, hacked, or just accidentally copied, it remains protected. In summary, don’t rely on “permissions” to protect files – secure their contents using encryption so even if your systems are breached, your data is safe.

For more information, view our webcast on “The Day in the Life of a File” where we present the challenges of protecting files and how encryption technology can be utilized to best protect the files in your organization.

PGP recently held a webcast on email data protection to cover considerations about email protection along with information about the latest product release.

• Replay in English
• Replay in German

We didn’t have time to address all of the questions during the webcast, but I wanted to circle back and provide answers to the remaining questions from the Q&A.

Q: Does PGP have a client available?
A: Yes, PGP Desktop Email is a client-based approach towards email encryption. It provides end-to-end email encryption ensuring that information says protected all the way from the sender to the recipient, no matter what networks or systems it traverses.

Q: Can the PGP platform handle different encryption policies between internal and external email?
A: Yes, the policy engine in PGP Universal Server uses a rule set that’s similar to setting up a chain in a firewall policy. You can set up policies to handle the email routed internally differently that email routed externally.

Q: What are the security considerations for a) sending a password protected Word document B) using a natively protected PDF and C) using PGP for encrypting email?
A: When using a password protected Word document, the sender must choose a password and deliver it to the recipient along with the encrypted document. Obviously, both cannot be sent in the same message because it defeats the purpose of protecting the document in the first place. Thus it introduces the problem of how to safely share a secret through some other means. The problem may be bearable if there is only one recipient, but it gets far more complicated as the number of documents increases and as the number of sender/recipient combinations increases.

A password protected Word document also does not have the ability to  provide tamper resistance. An attacker that knows the correct password could fraudulently modify and re-encrypt the document to the same password.

A password protected PDF uses a password as well, but the key difference here is the password management performed by PGP PDF Messenger. Instead of the sender setting the passphrase during the creation of the document, the recipient sets their own passphrase, thus removing the burden of managing a shared secret. As email passes through the gateway, it is encrypted and protected with the recipient’s passphrase.

With an end to end solution, such as PGP Desktop Email, neither user needs to exchange the secret information used to decrypt the file. By using public key cryptography, each user keeps their own secret key and distributes their private key, thus getting around the issue of sharing a secret and password management. PGP Desktop Email provides protection for the email from the sender’s computer all the way to the destination, thus protecting the data no matter where it travels. In addition, with the digital signature capabilities, the recipient knows that only the sender could have created the email, thus preserving the fidelity of the data and confidence that the information is reliable.
Q: In your experience, how hard is it to train personnel on how to correctly use PGP?  Incorrectly used encryption usually means it was unencrypted.
A: For PGP Desktop Email, the users typically have a passphrase that protects access to the private key. Based on policy, the organization may choose to have the user enter the passphrase once per session, or more frequently for more security conscious organizations.

For deploying PGP Universal Gateway Email, there is no training at all necessary for end users – it’s completely transparent to them.

Training requirements are very small – in most scenarios there isn’t end user training necessary outside of a notification of how to use the new environment.

Q: Can open source encryption software allow intercepted email to be read?
A: The open standard RFC4880 defines the format for OpenPGP, and supported by a number of products. An open source implementation of the standard is available through Gnu Privacy Guard (often known by its initials GPG), which is interoperable with PGP email encryption.

The answer to your question is no, even users of compatible software would not be able to intercept and decrypt the information without possession of the private key. The private key is what makes the difference between interoperability and unauthorized access.

Q: How would you go about encrypting an email in a small office where email is being provided by an ISP such as Verizon, Time Warner or AOL?
A: For many of our users who have a small deployment, they often start with PGP Desktop Email. PGP Desktop email can be run in a standalone environment (without needing a server), thus making it possible to deploy in small/medium businesses rapidly.

The mail servers provided my ISPs typically provide access to email via the standards SMTP (for sending email) and POP3/IMAP (for receiving email). PGP Desktop Email supports these standards and the information stays encrypted as it passes through your ISP’s mail server.

Q: Is PGP a hardware or software solution?  Where is the appliance (if hardware)?
A: PGP’s server software (PGP Universal Server and PGP Universal Gateway Server) is a software-based solution. The software runs as an appliance, meaning that administrative work is done through a web based interface and not through a shell.

Q: Can I use the same client license that is used on a laptop for a BlackBerry?
A: Those are actually two different products. The software running on a laptop is PGP Desktop Email, which is separately licensed from the Support Package for BlackBerry.

Q: Is PGP Universal Server location independent of the mail server location? For example, if the mail servers are located in the cloud, can we implement universal server locally?
A: Yes, there are a number of ways to deploy PGP Universal Server and PGP Universal Gateway Email. You can use set up Universal Server in parallel to an email server or in line with the mail stream. The location of the mail server can be in any location, including in the cloud.

Q: Where is the proxy?  Is it on a server or at a PGP hosted location?
A: It depends on which proxy you are talking about. PGP Desktop Email runs as a local email proxy, meaning that it actually runs on the user’s computer. The email client connects through the local proxy, which in turn provides the email encryption services.

PGP Universal Gateway Email is a standalone email server proxy that automatically encrypts email as the mail flow passes through it.

In both cases, PGP does not host the proxy but rather provides the software for an organization to set up their own.

Q: How does the recipient receive the passphrase to open the PDF?
New recipients receive an invitation to set their passphrase. Once the recipient registers the passphrase, PGP PDF Messenger can encrypt the message and deliver to the user.

Q: What isn’t all email being encrypted by default?
Policy in PGP Universal Server can encrypt all email by default. It depends on the organization to set an appropriate policy for their particular needs.

Q: How does incoming encrypted email get through Anti-virus/anti-spam engine?
If you’re referring to a gateway-based anti-virus/anti-spam engine, there are several approaches that you can take.  The first solution is to put the anti-virus/anti-spam products in line with the email gateway, so it continues to process email after decryption. If you’re using desktop email, a different approach is necessary. Because the email arrives at the gateway encrypted, it must be decrypted before being processing by the anti-virus/anti-spam system. This can be done by using PGP Universal Server / PGP Universal Gateway Email features for using the Additional Decryption Key (ADK) to produce plaintext to handle integration with message hygiene solutions.

Q: Will HTML Stripping corrupt the message or make it unreadable?
A: The PGP message uses a MIME encapsulation to transport the message. If your organization is using some type of HTML stripping solution, it should apply only to the MIME types that contain HTML data, and leave other MIME types untouched.