The JW Secure Informer logo
 

archive blog contact

A vision for hardware
data protection

JWSecure informer imagery

On the internet all devices are just an IP address

We've written previously on the importance of ensuring that a computer is operating correctly on behalf of a user. There are a wide range of examples of that, from a smartphone-initiated personal banking transaction to a web server accessing a database server within the confines of a datacenter. Before any enterprise allows critical data onto a device, the device must be well identified and secured from attack.

Modern business requirements are such that employees and partners throughout the world expect ready access to data from a wide range of devices. IT professionals must ensure timely responses while preventing data loss due to sophisticated attacks and enterprise security policy drift. However, even devices behind an enterprise firewall are being regularly hacked. Web application servers are a notorious example. Each hacked web server becomes a Trojan Horse within the walls of the IT fortress.

How do we prevent the bad guys from getting inside the fortress that is our datacenter? Furthermore, given the standard security guidance of assume breach, how do we prevent the bad guys from pouring out, once inside, and taking over the whole place? Proofing of data access requests that arrive at each individual server is critical. Threats against data include spoofing the user or the device requesting access, modification or denial of timely response to the user, and unauthorized disclosure of the plaintext data. Sensitive content must not only be protected with strong encryption. It must also be exposed only to strong identities and high-integrity systems, whether they are remote or within the datacenter. Enforcing protection for such a model requires that data only be accessible to systems that are known to have been good when issued and remain secure during use.

We recommend data protection based on a foundation of hardware-protected device identity. Then, built on that foundation, the following capabilities are required:

  • Data protection enforcement is local to each server.
  • Data that is dual-layer encrypted, at rest and in flight, until rendered for display.
  • Data is rendered into plaintext only in a protected environment.
  • User authentication does not hamper the security analyst (but nor is the security analyst account a single point of failure).
  • Techniques for handling device or user termination or abort are robust.

Where most IT departments are today

Current commercial technologies are inadequate to mitigate attacks that come from within the enterprise trusted ecosystem. There are several reasons for this:
  1. Server identities expressed using Public Key Infrastructure (PKI) are an improvement over server identities authenticated using static passwords, but server-side PKI typically uses software-based keys that are easily exported. Only hardware-based device identities are truly secure.
  2. While server authentication is common in client connectivity protocols such as TLS and 802.1x, strong authentication is less commonly enforced in machine to machine scenarios such as accessing backend storage (e.g., SMB; SQL) and datacenter management (e.g., virtual machine migration). Authorization must instead be enforced at every hop.
  3. Advanced cyber-attacks such as Pass the Hash and rootkits are increasingly prevalent in the datacenter and are difficult both to detect and to stop from spreading. Server-side data protection must account for the integrity of the end-to-end operating environment when authorizing a connection request.
  4. Maintaining the invariant of dual-layer encryption is difficult enough to configure and deploy, let alone to actually enforce. However, without enforcement, security policy drift is unfortunately the norm in enterprise computing.

Where we want to take you

Most commercial operating system and hardware platform combinations support virtualization and secure execution. However, integration of these capabilities into a system that enforces continuous authorization based on hardware root of trust is the novel capability of JW Secure StrongNet. We recommend that the following technologies be employed in concert:
  • Data encryption keys protected by the TPM
  • Virtualized container for rendered documents
  • Measurement based access to keying material
  • Deletion of plaintext content when compromise is detected.

Users need ready access to business data content over on-again/off-again connectivity. However, that need must be balanced with business continuity, intellectual property protection, and reputation needs. In other words, service high-availability must not come at the expense of data protection. Data should only be exposed to authorized users on known-good hardware in a secure state.

First, for managed devices, the ability to ensure that hardware remains in a secure state is diminished when the device is disconnected from the management network. Downloaded plaintext data is vulnerable. Therefore, first off, we need to limit by policy the period of time during which downloaded plaintext data remains accessible.

Second, whenever any secure app is suspended, any protected content that is contained in its cache will be cleared and must be decrypted again after the app is activated. Example scenarios include the laptop of a business executive left in a hotel room.

Third, device software should decrypt content only when authorization conditions have been met. The service should determine the integrity of the software on the device continuously. To this is added the information about user identity, device identity, and whatever additional context is relevant to the authorization decision. The combination of device integrity and authentication data for the user and project parameters, such as time and location, are used to create wrappers for the content decryption keys. Note that content decryption keys can be included in several key wrappers with different users and projects, where projects should be interpreted broadly to include groupings like physical locations or even device types.

Fourth, a render engine (for example, for DOCX, XLSX, and PDF documents) must be selected that supports the standard document encryption technology. It's important to protect the decryption key in use by putting the render engine in a space that cannot be accessed by any other application. Several technologies are available to place the render engine in an isolated environment. We propose to show hardware virtualization performing this function. The display image is eliminated whenever the device power cycles, requiring renewed authorization and decryption.

In summary, decryption of new content must not be possible until the user and the device are successfully authenticated. JW Secure can show you how binding hardware-protected cryptographic keys to environmental measurements such as time and behavior. We call the technique Measurement Bound Keys (MBK). An MBK can then be used in any scenario that calls for asymmetric cryptography and/or PKI without modification of the host application. Any change in measurement forces the key to be reauthorized. Therefore, as long as the key remains usable, the data owner knows that the host is provably secure.
 


Keep in touch

RSS
Facebook
Twitter
Contact
 


Just for laughs

JW Secure Informer cartoon


Quote of the month

You can tell more about a person by what he says about others than you can by what others say about him.
 
- Audrey Hepburn -

Thank you for reading the JW Secure Informer

The JWSecure Informer is a bimonthly newsletter that can be sent directly to your inbox. Please add sales@jwsecure.com to your safe sender list. To subscribe, or contact Customer Care, use the links below.
 
Update Your Preferences | Subscribe | Contact Us | Privacy Policy
This information has been organized and published by:
 
JW Secure, Inc.
1752 NW Market St. • Suite 227 • Seattle, WA 98107
© 2016 JW Secure, Inc. All Rights Reserved.