Exam Papers Encryption Project PGP Universal Server Trial Progress Report Introduction Using encryption for secure file storage and transfer presents a number of challenges. While the use of strong, well recognised encryption algorithms may 'solve' the problem of appropriately securing files in storage and in transit, the use of encryption itself does not imply complete security or confidence. Rather one problem is solved, but a number of others created, and it is dealing with these challenges that provides the overall level of security for the cryptographic system. Furthermore, there is no such thing as a 100% secure system and 'security' should be thought of as being appropriate (or not) for the task in hand. There will always be some trade-off between security and usability and this will usually be determined by user requirements and risks. For the purpose of this trial we can think of the encryption used by PGP as public-key (or asymmetric) encryption (PKE). The main requirement for the management of keys used with public key algorithms is that the private key remains secret, the integrity of the public key is guaranteed and that their use is controlled. Other issues to consider in order to securely implement public key cryptography include: key generation & storage key lifetime key usage key distribution key revocation and destruction Some of these issues were highlighted in previous trials of both PGP and GPG. In particular mistakes were made when it came to key generation and distribution (e.g users disclosing their private keys). It was also suggested that other requirements might include certain culture training (e.g. the need for general good security practices, strong passphrases, etc.), key escrow (to mitigate against the risk of 'losing' an encrypted document), and the need for some sort of Public Key Infrastructure (PKI). PGP Universal Server was identified as one product that would allow central management of keys, policies and software and possibly offer some of the benefits of PKI. This report aims to summarise the progress of the subsequent trial of PGP Universal Server and raises a number of issues which need to be addressed. PGP Universal Server Findings So Far PGP representatives initially came to OUCS on 11/09/2007 in order to help install PGP Universal Server, roll out a small number of test desktop installations, and set up an example mail policy that would allow users to invoke encryption via the subject line. Progress was halted until the turn of the year due to the discovery of a bug in PGP Universal Server's email enrolment process for PGP Desktop. Following a new release of the software, the project was resumed on 10/01/2008 when a PGP representative again visited Oxford. The server was updated and the bug in the enrolment process had been dealt with to the extent that progress was possible. Installation of one Windows based client was successful. Since then PGP offered two places on a training course at PGP's headquarters in Offenbach, Germany. This was attended by myself and Tony Brett, who both returned as PGP Certified Technicians. Time since then has been spent testing the software and setting up policies. A number of 'problems' have been found with the software resulting in multiple support calls to PGP. Two of these are ongoing and include a issue relating to the original enrolment process problem (although we do have an acceptable work around). Two other calls turned out to be the result of questionable functionality, and have prompted the submission of feature requests. More issues are anticipated - initial testing of OSX installations, for example, have highlighted a number of potential problems, the extent of which should become apparent when the trial is extended to include other end users. Currently there are a number of issues that need resolving in order for the trial to progress, and these are discussed below.
Key Generation and Storage There are a several factors to consider when it comes to key generation and storage, and PGP Universal offers a number or options. The 'best' solution will depend on the specific user requirements. In terms of key generation PGP Universal's default settings consist of an RSA keypair with a key size of 2048 bits. RSA is common, well trusted algorithm used widely in PKE and is compatible with GPG. In today's current computing environment (i.e. in terms of processing power etc.) 2048 bits is considered a secure length for RSA keys. In terms of this project, and the options PGP Universal offers, there are two possible solutions to consider for where keys should be stored. These are Client Key Mode (CKM) and Guarded Key Mode (GKM). In CKM the keys are stored on locally on the user's machine only, whereas GKM keeps a backup copy of the user's private key (encrypted) on the server. Some of the issues with each key mode are described below. Key Type Risk Possible Mitigation Advantages CKM 1) User loses private key (e.g. disk failure) and is unable to decrypt documents. i) Documents are always encrypted to another key (see Key Escrow & ADK below) ii) Key Reconstruction is enabled (see below) User is solely in possession and charge of their own private key. This may be particularly important where non-repudiation is a requirement. GKM 2) Exposure of a user's private key. i) Key is stored encrypted on the server protected by a passphrase therefore enforce the use of strong passphrases. Backup copy of key readily available in case of loss, or in the case of a user installing further copies of PGP Desktop. Key Management and Usage Key management proved to be one of the main areas for concern following the testing of the PGP Desktop standalone client. Notably a number of users failed to keep their private keys secure, and struggled with the distribution of keys. PGP Universal Server was therefore considered for its ability to manage encryption keys and policies, with the intention of making email encryption as transparent to the end user as possible. Specifically it was decided to test the possibility that an end user could invoke encryption of an email via, for example, the subject line of the email. The centrally controlled email policy would then decide what to do with that email (e.g. send encrypted, send in plaintext, reject, etc.). There are, however, a number of considerations to be made regarding this approach. These are discussed below. Email Encryption PGP Desktop acts as a proxy between a user's mail client and the mail server. Therefore encryption happens once an email is sent. The process is simplified as follows: Sending 1) User creates email message to be encrypted and clicks 'send'. 2) PGP Desktop 'intercepts' the message on the client machine and chooses whether to encrypt and send or not based on a centrally managed policy. 3) Message is sent either encrypted or in plaintext via the outbound mail server. Receiving
1) Incoming messages are 'intercepted' by PGP Desktop. 2) PGP Desktop will decrypt, if necessary/possible, and deliver the message. Given the requirements for this trial, the main advantage of this approach is the fact that the data is protected on the communication channel and the key management is handled by PGP Universal Server, where policies are centrally managed. All the user has to worry about when sending a message is "does this message need to be encrypted", and remembering their passphrase. Similarly the user does not need to worry about whether or not they can 'trust' incoming messages that are encrypted to them. The only thing they may need to do is enter their passphrase to be able to decrypt messages. One disadvantage with this approach, however, is that messages are stored in plaintext (i.e. not encrypted) on the client machine and encryption/decryption of messages only happens when the message is proxied by PGP Desktop. There are two main issues to be considered with the current implementation of PGP Desktop: 1) Used in this way alone PGP Desktop only protects data in transit, not in storage. 2) PGP Desktop does not proxy messages when they are copied to other folders, the most obvious example being the sent-mail folder. In the case that these folders reside on a server (e.g. an IMAP server), those messages will be transmitted and stored remotely in plaintext. There are therefore a number of possible mitigations: Mitigation Reason Disadvantage Do Nothing Do not copy messages to remote folders. Encrypt files first and send as attachments. All connections to Oxford Mail Servers are already encrypted via SSL/TLS Prevents messages being 'sent' across the network in plaintext Sensitive files stored/distributed encrypted - regardless of medium - until they are actively decrypted. i) Messages stored remotely in plaintext. ii) Other mail accounts ( and therefore servers) which allow non SSL/TLS traffic may be used. i) Users will need to store 'sentitems' folder locally - may be inconvenient. ii) Needs to be policy to say that users must only store messages in local folders. iii) May be inconvenient to the user, easily forgotten and difficult to enforce. i) Additional requirement to be able to encrypt files prior to sending. ii) Need for public key distribution - introduces traditional PKI problems (see below). Public Key Infrastructure (PKI) Should it be a requirement that users are able to encrypt files to the public encryption key of other users a few traditional PKI problems begin to appear. As already mentioned, apart from keeping private keys secure, the other main requirement for PKE is that the integrity of public keys are guaranteed and that their use is controlled. Some of the reasons behind this are briefly explained below from the point of view of the sender and recipient of encrypted communications. The sender needs to be able to: 1) Obtain the public encryption key of the intended recipient. 2) Trust that the public key they are going to use actually belongs to the intended recipient. 3) Have some assurance that the key is still valid for use.
The recipient needs to: 1) Make sure that their own public encryption key is available for use by others. 2) Trust the source of incoming encrypted communications. In terms of using PGP Desktop/Universal Server for this project, there are a number of available approaches. Put simply, they are to use PGP Universal Server as a key server for distribution of public keys and/or allowing users to manage their own keys. Taking the sole option of allowing users to manage their own keys takes us back to the original problems faced before the trial of PGP Universal Server so this will not be discussed here. What follows, therefore, is based on using PGP Universal Server as a key server, with the additional option of allowing users to manage their own keys. PGP Universal Key Server PGP Universal Server offers the option of running as a key server. This, basically, allows users to query the server to search for, and download, other public encryption keys. One potential drawback is that this may allow non-trusted users to obtain public keys for encryption. While public keys are supposed to be published for use by others, some authentication of the source of any correspondence is needed, as encrypted communications could be used to obfuscate malicious content such as malware. Access to the key server can be restricted by IP address and so one mitigation against this risk would be restrict access to Oxford IP addresses only. Further testing is also required to ascertain the extent to which PGP Universal Server's mail policy allows for vetting of the source of any encrypted email/content. Key management As mentioned, allowing users to manage their own keyrings is an additional possibility. Some of the pros and cons are discussed below: Key Management Pros Cons Risks Possible Mitigations Users able to manage keys locally Users prevented from managing keys locally 1) Ability to download keys from server and store on local keyrings. 2) No need to look up public keys on the server every time. 3) Introduces the possibility of key expiry and revocation. 4) Users free to export their own keys either for distribution or backup purposes. 5) Users can search external key servers. 1) Reduced risk of users mismanaging their own keys (e.g. exporting private keys). 2) With the use of a closed PKI, access to users' public keys can be restricted to 1) Users could mismanage their own keys (e.g. export and distribute their private key as seen in the original trial of PGP Desktop) 2) Users could be fooled into accepting and using 'nontrusted' keys on their own keyring. 3) Users can search external key servers and possibly download/use untrusted keys. 1) Users required to query the key sever every time a public key is needed. 2) Key revocation and expiry not available. 3) Restricted key servers could a) Risk of user's private key being compromised. b) User could send encrypted files to a non-trusted destination. a) No way for other users to tell that a public key they posses should no longer be used. Therefore: i) They could encrypt sensitive files to that i) User education. i) Implement some form of PKI. ii) User education. iii) Use of PGP Universal Server email policy to restrict key search (only effective for email controlled via policy). i) Delete keys from the Universal Server in the case that keys should no longer be used.
'trusted' sources. 3) Key searches are restricted to certain key servers. possibly hamper a user's key search. key which could be decrypted by an attacker. ii) An attacker could potentially create 'trusted' digital signatures and impersonate the legitimate key holder. Lost Keys and Key Lifetime One final issue, with regards to PKE, is that of what happens when a user loses their private decryption key. Clearly once a private key is lost it is no longer possible to decrypt any ciphertext that has been encrypted using the corresponding public key. Therefore there is a risk of the documents themselves being 'lost'. PGP Universal, again provides a number of possible mitigations against such a risk which are as follows: 1) When sending files to other users, always encrypt to your own key as well as theirs. It is possible to set this functionality via user policies defined centrally on PGP Universal Server and it makes sense to do this as users would probably want to be able to decrypt the files themselves. While this means there is less chance of a file being lost it is not a very satisfactory solution on its own. 2) Backup the user's Private Key. The user could keep their own backup copies of keys if they are allowed to manage their own keyrings, or backups could be kept on the server in the case of GKM. Both of these options have already been discussed in depth. 3) Key Reconstruction. PGP Universal Server allows the option to set up key reconstruction as part of the enrolment process. If selected, a backup of the user's private key is split into a number of components during the key generation phase. When enrolling, the user selects and answers a number of pre-defined security questions. If a user then loses their key, they must answer those questions correctly in order to 'reconstruct' their private key. This option could also be used if a user needs an additional copy of their private key (for example if they are installing a second copy of PGP Desktop). This gives the user the chance to rescue their key themselves, though there may be good reason for not allowing this. For example, if a user's key is compromised in some way, then it may not be desirable to allow them to carry on using that key. It is also possible that a user could forget the answer to the security questions (which happens frequently in the case of Oxford SSO security questions), or worse that someone else could easily guess, or work out, the answers to those questions. 4) Additional Decryption Key (ADK). This is basically the concept of key escrow. In other words all files/communications that are encrypted, are also encrypted to a master key. Clearly there are privacy issues with such a solution and key escrow is a controversial and strongly debated topic. In order to maintain the privacy of users then no one person should have access to the ADK and PGP allows you to split the key into components - each of which can be weighted. When the ADK needs to be used it is therefore 'reconstructed' and can only be used when a certain pre-defined 'weight' has been reached. Therefore if ADK is deemed necessary/desirable, who has access to the components, and the relative weight of those components will need to be decided. Clearly there will also need to be some agreed policy/process to define the use of the ADK. There are also also possible
legal/regulatory issues that will need to be taken into consideration which are discussed briefly below. Of course, when keys are lost it should be taken into consideration whether the integrity of the key has been compromised before a key is restored. Similarly keys could be known to be compromised, or have reached a stage where they should no longer be used (e.g. no longer secure, no longer required by user, etc.). At the end of their lifetime, keys should be revoked and securely destroyed. Key revocation has already been mentioned throughout this report so will not be discussed in depth here, but should be taken into consideration when deciding on a number of the above solutions. Encrypting Stored Data Perhaps the greatest risk to data being stored on a computer is how the data is actually stored. While data encrypted in transit can still be intercepted it should remain confidential, however that does not protect the files when they are stored on the local machine. Clearly, networked machines are at risk from unauthorised access, but similarly hardware can be stolen, computers shared etc. While the requirement for this project was that data should be protected during transmission, this does not satisfy the recommendation that files should be encrypted at the point of creation. The notion of allowing users to encrypt files to public keys has already been mentioned. PGP Universal/PGP Desktop also allows the option to create an encrypted virtual disk. While this wouldn't protect the data when the disk was mounted (i.e. being accessed) it should provide some protection when the disk is not mounted and also in the event of the hardware being stolen/lost. While PGP Universal/Desktop email gives protection to data in transit it should be re-enforced that this does not protect data in storage and so some consideration should be given as to whether or not this is acceptable. Passphrase Policies and Good Practice Of course encryption on its own is not the answer to all security problems associated with electronically communicating and storing exam papers. As well as strong key management, general good security practice should be followed and all users made aware of their responsibilities. If an attacker has control over a user's machine, or is able to access information in some other way (e.g. social engineering, shoulder surfing), encryption offers no protection at all. One obvious weakness when using keys for encryption is how users are able to access and use those keys. In PGP keys are stored encrypted, but there must be a means for legitimate users to access those keys, and this is done by way of a passphrase. This means that any decryption key (no matter what algorithm or key length is used) is, at best, only as as strong as the passphrase used to protect it. If a passphrase can be easily guessed or 'brute-forced' then the 'strength' of the key is irrelevant. The minimum recommendation, given the options available using PGP Universal Server is therefore that the passphrase should be a minimum of 8 characters long AND have a 'strength' of 65% (meaning the passphrase has approximately 83 bits of entropy). One problem often encountered with setting strong passphrase policies is that users a) complain about having to remember another password, b) forget their passwords and c) end up writing them down. In the case of encryption, enforcing strong password/passphrase policies is paramount to the overall security and integrity of the system. Users may therefore require awareness (or 'culture') training in the reasons for, and use of, strong passphrases. Equally, other general good practice should be promoted to end users (e.g. keeping AV up to date, patching, reporting of incidents, safe browsing habits) and all users of the system, from administrators, down to end users should be made aware of their responsibilities towards security. Legal Issues It should be noted that this is not legal advice and is not written from the point of view of a legal expert. However there should be some awareness that there are certain legal issues that may affect certain policy decisions, and that may need to be dealt with via policies themselves. For example different countries have legal restrictions on the import, export and use of cryptographic technologies. Perhaps more immediately relevant is the the new powers of law enforcement in the UK to require that decryption keys (or the relevant plaintext) should be presented under certain sections of the Regulation of Investigatory Powers Act (RIPA). Thought needs to be given to who would be responsible for providing keys and/or plaintext if such a request was made.
Summary In summary, PGP Universal along with PGP Desktop has the potential to solve some issues surrounding the communication of exam papers in preparation (and other confidential documents) via electronic means. So far a number of 'bugs' have been found in the software and certain features (or the lack of them) could be questioned, from a security perspective. However this really depends on the requirements of the system and what is considered an appropriate level of security and usability. The email solution on its own is, potentially, the most seamless approach from a user's point of view. However there are notable weaknesses such as the fact that messages that are not proxied (e.g. 'sent-items') are not encrypted, and that data is not protected end-to-end from the point of creation. There are a number of additional measures that can be used to provide a 'more secure' solution, but then some familiar problems (which were trying to be avoided) begin to appear. Ultimately decisions need to be made on what is an appropriate level of security. Additionally, for the suitability of the product, and the success of the trial to be measured, the requirements for the system need to be clearly defined.