Weaknesses in the SSL protocol (the protocol for encrypting information over the internet) or the public certificate authority (CA) ecosystem that underpin it have received a lot of coverage recently and the last couple of weeks have been no exception. The pervasive nature of SSL and its unique role in securing ecommerce and numerous cloud services makes SSL attractive to security researchers and attackers alike. However, many of the lessons learnt are in no way specific to SSL and must be applied to other Public Key Infrastructure (PKI) and encryption deployments if we're to avoid handing potential attackers a skeleton key to access our sensitive data or critical infrastructure:
While this is all good news for anyone who cares about the confidentiality and integrity of sensitive communications, there’s also a catch. Organisations face the challenge of deploying ever more sophisticated real-time intrusion prevention systems (IPS) and data loss prevention (DLP) solutions to protect against data leakage or intrusion. However the trend towards an increased reliance on SSL and the removal of the truly transparent MITM option by purchasing a sub-CA certificate will force organisations to augment every workstation’s trusted Root CA store with their own internal CA Root.
The result is a hybrid PKI with a mix of public and private CAs and the potential to create a new internal point of attack if the internal PKI is not well planned and deployed. As the trust in the public CA ecosystem grows, organisations in a rush to deploy a web security gateway should take great care to avoid generating a weakly generated or weakly protected software key that is then trusted by all of their workstations. The existence of trust in such a key has the potential to be a gift for an attacker.
A properly planned and deployed private CA can work well where all machines are administered by a single authority. The next hurdle the industry must face is that this sort of implementation doesn't scale well across organisation boundaries and gets even more difficult in a "Bring Your Own Device - BYOD" environment. But that’s a topic for another day...
Mark Knight
Sometimes it takes a very public breach for the shockwaves to force an industry to tighten up security. I welcome the news that the Certificate Authority (CA) industry body that initially specified the standard for Extended Validation (EV) certificates has now published requirements (or standards of due care), for the issuance of publically trusted certificates. Certificate authorities that have signed up to the new requirements have 6 months to comply.
Specific requirements that stand out include:
• Mandating the use of larger/stronger cryptographic keys (e.g. no use of 1024bit RSA keys)
• Mandating that CA signing keys must be protected in a FIPS 140-2 level 3 certified Hardware Security Module (or Common Criteria equivalent)
• Placing liability on the CA to defend any browser vendor who suffers losses or claims as a result of a CA breach
• The CA must enforce the use of multi-factor authentication for all accounts capable of causing certificate issuance
Attackers usually target the weakest defences in any security chain. I hope the CA industry will now start to recommend similar standards of care to help their subscribers, but why wait? The theft of a digital certificate can amount to corporate identity theft. Just as we as individuals all have a responsibility to protect our personal identities (and can suffer a lot of expense and embarrassment if our identities are stolen), organisations need to enforce internal standards of care to ensure they don’t become the victims of cybercrime. The only difference with corporate identity theft is the potential scale and impact of the losses.
Mark Knight
It's good news that Google have announced their continued expansion of the use of SSL which means that certain Google searches (and the results) will be encrypted. There's already been pressure to turn on encryption at corporate and domestic WiFi hotspots to prevent theft of passwords and other information by sniffers on the local hotspot but it must be remembered that this still only protects communication between the user's computer or phone and WiFi access point. Traffic flowing on the wired network across the various hops and interconnection points that make up the internet to get to websites such as Google is typically unencrypted. The solution is for web site operators to deploy technologies like SSL to provide end to end encryption from the consumer all the way back to their site. It's good to see that https (aka SSL), is now gradually replacing http, even for free services like Google search.
However despite the onward march of encryption, SSL has recently suffered from some bad press. High profile breaches at public certificate authorities who are responsible for issuing the digital certificates or identities that enable our browsers to verify the authenticity of the sites we visit and concerns over the security of older versions of the SSL protocol itself are good recent examples. Any casual reader who browses the technology headlines must be confused; when they see the familiar padlock on the corner of the browser can they trust it or not?
What can the industry do to help? Two immediate things:
1. At least make it easy to keep everything up to date: The browser itself is our first line of defence. Browser and application vendors should streamline and automate the process of pushing browser updates to clients. It shouldn't be necessary to perform a firmware upgrade or download megabytes of software to update the trusted certificate store on a workstation, tablet or phone. The 'app revolution' shows us that updates don't have to be painful.
2. Enable online trust to be a true differentiator: Security isn't a binary choice of "secure" or "vulnerable" and simply using the SSL protocol is not sufficient to guarantee security. Users need the ability to differentiate between "very secure" and "probably secure" - after all the security you would like for a Google search is probably not the same that you would need for online banking. The concept of Extended Validation Certificates (EV) has started us down this path but now these schemes need to be extended to offer broader guarantees of website security. Over time browsers can use this information to show users the actual level of security that is being provided, end-to-end, offering a strong incentive for organisations such as banks, retailers and service providers to deploy the strongest defences for their websites and recognised by their customers for doing so.
Mark Knight
Since the European Commission outlined its overhaul of EU data protection laws in June (see earlier post here), debate has continued about the scope and impact of the reforms, especially in reference to cloud computing.
The draft document is not due out until November but there has been considerable speculation on the details of the Directive, particularly over whether it will shift liability to the cloud provider in the event of a data breach.
It has been suggested in some quarters (see here) that the updated Directive will include a provision ‘asking’ cloud providers to validate the security properties of their service infrastructure and to accept legal responsibility for any data losses that occur while that data is in their custody. It is suggested that cloud service vendors who signed up to the scheme and accept legal responsibility would have a competitive advantage. This would be based on customer confidence derived from independent validation, compared to vendors not signed up to the scheme.
In principle this could help to drive adoption of cloud services, particularly those associated with handling sensitive data. But you have to question the logic of that argument.
Firstly, the prospect of a shift in liability sounds appealing but is it really going to make a difference? Even if your cloud service provider is held legally responsible for losing your customers’ data, it’s still your customers’ data that is lost and your reputation that is damaged. Imagine if an online retailer were to lose customer credit card details as a result of a hacker infiltrating a cloud vendor’s data centre. Irrespective of where legal liability lies, it is still the retailer that would have to disclose the breach to its customers and suffer the financial and reputational damage.
Secondly, there’s the practical issue that virtually no cloud providers will be prepared to accept liability. Few cloud providers have any knowledge of the data that they process and have no ability to calculate the value or risk attached to it. The controls and monitoring systems that would be necessary to support the technical and legal finger pointing to establish the source of a breach would be too overwhelming.
Thirdly –accrediting cloud services from a security perspective is somewhat of a lofty goal. In the enterprise sector, PCI DSS (which has a much narrower focus) has still taken years to create and relies on a huge network of supporting parties. To define and enforce an accreditation scheme suitable for the numerous and diverse data types and security objectives involved in generic cloud services is, in reality, not feasible.
If the goals of the Directive are to stimulate the adoption of cloud computing and motivate cloud providers to take security more seriously, then it’s a worthy cause. But security is such a contextual concept that it’s almost impossible to apply blanket mandates. Cloud vendors provide a variety of services that handle different types of data that are subject to different protection requirements. It is up to the organisations taking up their services to evaluate whether a cloud provider can meet their SLA requirements and be trusted to safeguard data, or not.
Richard Moulds
Following the catastrophic security failures at both DigiNotar and Comodo that led to a single attacker obtaining numerous falsified SSL certificates and the subsequent large scale misdirection of traffic in Iran, 2011 looks set to be a defining year that may change the landscape in the PKI world for years to come.
While vendors, consultants and regulators have advocated the benefits of PKI and define security practices and standards to ensure the integrity of the infrastructure upon which all e-commerce depends, attacks have typically been theoretical. Now there’s undeniable evidence that the threat is real. And while the recent attacks have (eventually) become public knowledge I cannot help but wonder how many other breaches remain undiscovered or unannounced.
These attacks have thrown into sharp focus several weaknesses that stem from the widespread assumption that a Certificate Authority’s systems are always trustworthy and that a certificate is only revoked if the holder loses their private key (e.g. if a web server is hacked), or if the holder’s entitlement is withdrawn (e.g. when an ID card is revoked at the end of an employment). In other words it has previously been assumed that a certificate is always genuine and valid on the day it is issued.
It can be tempting to assume that certificate revocation solutions such as the Online Certificate Status Protocol (OCSP) are effective at controlling the impact of a CA breach. However as currently implemented, OCSP isn’t a reliable solution to the threat of falsified certificates. Firstly not all applications support OCSP (such as mobile devices and older XP based systems), and where OCSP is supported, the default configuration is often to trust a certificate even if the revocation service cannot be contacted (this is the default with IE9 and FireFox 6). As a result, any attacker who can hijack IP routing or DNS can simply block access to the corresponding OCSP responder. Secondly, browsers only check for certificate revocation using the OCSP responder that’s listed in the certificate they’re validating. If that certificate is falsified this revocation information cannot be trusted anyway unless the entire CA is revoked!
Relying upon timely and effective revocation using mechanisms like OCSP can never be the complete answer; especially since one of the primary benefits of many PKI based solutions is the ability to validate identity in an offline environment. The industry needs to find ways to increase the integrity of the certificate issuance process itself. The response to the recent attacks is likely to be a series of more rigorous standards that mandate system-wide protection for certificate issuance, much as PCI-DSS has become a standard defining system-wide protection for credit card information. Standards may be defined by browser vendors who can choose which root certificates to include in their products. As recent events have shown these application vendors have a unique role in determining which CAs are trusted and ultimate responsibility for revoking untrustworthy CAs. Mozilla have already written to the CAs whose certificates they incorporate, requesting they undertake an immediate audit. Where PKI is already regulated (for example as used within Europe for e-invoice signatures), these regulators will be looking to strengthen the standards they enforce. Alternatively, the CA industry may choose to tighten self regulation in certain sectors, perhaps in an attempt to avoid external mandates.
CAs do now offer premium certificates in the form of Extended Validation (EV) certificates that promise increased assurance by defining an elevated standard for the procedural elements of identity verification. Unfortunately EV certificates place few additional responsibilities on the issuing CA to increase the protection of their internal IT systems and therefore don’t serve to protect against targeted hacking attempts.
Once identity checks are complete a CA uses a series of highly sensitive cryptographic keys to issue a certificate request. Today it’s routine for these valuable keys to be protected in a security appliance called a Hardware Security Module (HSM). By moving these keys away from standard servers and into an HSM they are protected from risks such as viruses and hackers. However other critical parts of the certificate issuance process still typically run on general purpose servers where, as in the case of DigiNotar, they can be vulnerable to attack.
The risk of a successful attack could be significantly reduced by moving more of the certificate issuance process into the protective environment of an HSM. Firstly this would ensure that all certificates are issued with accurate attributes including revocation details and date information. Secondly this will enable accurate and hardware enforced reconciliation between authorised certificate requests and certificates that are issued. For anything other than the least valuable certificates, where the identity checks are themselves automated, this issuing process should require manual two factor approval; e.g. requiring the physical presentation of a smartcard to confirm identity checks have been completed and to authorize the issuance of a certificate. The issuing HSM would then have the opportunity to validate this authorization and other business rules (for example checking the certificate is issued during normal working hours), before producing the requested certificate. This approach would dramatically increase the barriers a hacker must overcome to issue fake certificates.
Moving sensitive business processes into HSMs will take time, as existing certificate issuing applications will need modification. Other interim approaches exist; for example HSMs can provide a simple key use counter that provides an authoritative count of certificates that have been issued. Such counting features should be enabled and in the event of a mismatch, certificate issuance should cease immediately.
Until these issues are addressed and confidence is restored there’s a question mark hanging over the widespread trust of cloud based services. The assumption that a padlock symbol in a browser proves your connection to a service can be trusted is starting to be questioned. However while we should all be cautious, SSL and “https” will undoubtedly remain far safer than plain old “http”.
Mark Knight
Data breaches have certainly dominated the headlines during the past few months. The dust hadn’t settled around Stuxnet when the Sony and RSA incidents occurred. We have also seen less complex mobile phone “hacking” that has closed a national newspaper and dominated a government’s agenda. Now, recent reports have shown an increase on smartphone attacks with increased app, Android and iPhone incidents as hackers attempt to ascertain the treasure trove of personal information users are now keeping on their mobile phones. Is this the next fraud frontier?
Although there may be some similarities between smart phone security and server security in the enterprise, the problem could actually be much larger, maybe even ten-fold in the mobile world. There are many factors that cause this including unknown developers offering apps and the unique security challenges that make it difficult to build trust on a mobile phone. Just as the enterprise has worked to provide increased server security, the mobile industry will need to do the same now that the data available on a smartphone can be just as valuable as that on a server.
Everyone from phone providers to app stores should look at how enterprises have increasingly adopted hardware platforms such as hardware security modules (HSMs) as best practice for secure encryption and cryptographic key protection, and reflect on how the explosion of mobile devices will drive similar security requirements in an accelerated fashion in this highly mobile world.
Richard Moulds
A researcher has revealed this week how easy it can be to find the private keys that are supposedly securing organisations’ sensitive data. No clever hacks or tricks of the trade are necessary, just a simple Google search.
After he claimed that a web search on ‘BEGIN PGP PRIVATE KEY BLOCK’ gave 29,500 hits, I decided to test this out myself (with a few tweaks) and the number of keys out there is indeed staggering. It’s not clear how many of them are real or provide access to valuable information, but presumably some proportion of them do. And that’s worrying.
Many are probably thinking this problem doesn’t apply to them. Maybe they have passwords somewhere. Maybe they’ve checked their public folders and moved the keys.
However, what the above Google searching demonstrates is just how vulnerable keys are when they are not stored in hardware. These ones happened to be found by a web spider. But the same applies to keys inside an organisation once a Trojan or virus gets in and runs a spider of its own.
So, how protected are your keys? Try searching ‘BEGIN PGP PRIVATE KEY filetype:asc site:yourdomain.com’. If you get any hits, it might be time to revisit your key management procedures...
Jon Geater
Code signing is one concept not earning enough attention amid all the coverage of advanced persistent threats (APTs). A main reason APTs are an issue is because attackers can easily change application code or device firmware (that’s what makes them "advanced") without being noticed (that’s what makes them "persistent") and the threats are significant and don't necessarily involve just corporate data theft (think about malware on critical infrastructure, such as a flight computer in a plane, smart grids, or even traffic lights). Since the code runs on open platforms, the best line of defense is to make sure the software has not been modified by testing its authenticity.
Software developers will often enable their code to be tested prior to execution by signing their code digitally, effectively applying an embedded watermark. In the current climate, software publishers, be them creators of commercial software or in-house developers, are in danger of being viewed as irresponsible if they do not sign their code. However, such efforts do not appear to have worked in the case of many of the now well-known APT attacks.
The obvious questions therefore surround the trustworthiness of the signatures. Given the rise of APTs, I expect greater focus on trustworthy code signing processes as well as on digital signature laws. Fortunately, numerous methods exist to digitally sign code in very secure ways that are not a burden to the development process. Thales has built these systems for some of the largest software publishers in the world.
Needless to say, the use of HSMs addresses the potential trust issues related to code signing. By protecting secret signing keys the signatures can be trusted. HSMs themselves are certified to independent standards (e.g. FIPS) and can be used to enforce strict key management policies, which means signatures can be trusted across separate domains. Finally, HSMs include crypto-acceleration capabilities, which are important for organization doing lots of signatures.
Richard Moulds
As the final in a series of posts on key management in the Cloud, following are the remaining three possible strategies that organisations could look to adopt when thinking about how to secure their information in the Cloud.
The Just In Time Strategy is where keys and sensitive materials are stored on premise, only being released into the Cloud for a short time when needed. Quite a few companies are starting to offer such solutions with a large on-premise management system and a small software plugin for the Cloud applications which can fetch and use keys when needed. This is a promising model but it’s early days: watch out for highly proprietary systems, vendor lock-in and the need to modify applications directly to take advantage of the solution. And remember - the keys have still been exposed to the Cloud, no matter how briefly.
Next we have what I call the Mole Strategy, because you use tunnels. This is the logical conclusion of hybrid systems and provides a solution to the exposure issues of JIT. With a trusted hardware lynchpin or suitable access to a user-controlled secure element in the cloud, you can assert some control over key management by connecting to a trusted island in a whole sky of Cloud. This is not yet a reality but for security-conscious users it would be a real boon.
Finally, we have the Big Brother Strategy. Sometimes overlooked, the deterrent effect of strong auditing and oversight should not be underestimated. The use of hardware devices, cryptographic signatures and independent access control for audit keeping can vastly improve the trustworthiness and reliability of a log and provide an added deterrent. While this approach cannot prevent an event from happening it does provide excellent visibility which enables the organisation to make informed risk decisions about what data they can trust in the Cloud.
Whichever strategy you choose for your move to the Cloud, remember that your cryptographic keys are more than data, they are your promises. Keep them well.
Jon Geater
Having outlined yesterday the need to take an information-centric approach to key management in the cloud, today I would like to share the first half of a series of six strategies that could help organisations take this approach.
The first strategy I would like to outline is the Trust Everyone Strategy, where existing applications, keys and management tasks are fork-lifted from the datacentre into the service provider. No special steps are taken to address the control challenges introduced by the Cloud. However, as we all know, no matter what else you outsource you can’t outsource your responsibility, so this strategy is not really an option. I’m all for SLAs bridging the gap between business desires and technical reality but wholesale handover of sensitive operations is probably a bridge too far.
At the other end of the scale is the Trust No-one Strategy. No important cryptographic infrastructure is moved out to the Cloud. While very safe, and a good first step for hybrid deployment, this approach does not enable the greatest exploitation of all the Cloud has to offer.
For those who want something in between, the Trust Someone Strategy is possible. It is the first step in a genuine risk-based approach to moving keys into the cloud. Given some visibility of the operations of the service provider, you are able to make an informed choice about how much you release to their control, much like traditional outsourcing. Here you accept that a group of administrators and security personnel can affect your security but, given sight of hiring policies, systems management processes and internal physical security, that may be acceptable. Be on the lookout though for issues of multi-tenancy, the constancy of personnel management at the provider and the economics of providing strong separation between personnel and management systems. Also be sure you can find proof of whatever you’re relying on. What systems and processes give you independent proof that procedures are being followed and promises kept?
Jon Geater