The JW Secure Informer logo

archive blog contact

Open-Source Security for DevOps

Dan GriffinWelcome to the 42nd edition of the JW Secure Informer, our bi-monthly newsletter. This is an opportunity to share what's on our radar, specifically with respect to network security, but also regarding IT and business more generally.

Importance of Credential Theft Mitigation
Most security incidents entail credential theft. A common scenario is for a remote attacker to gain initial entry into an enterprise network by one of two ways:

  • Phishing
  • Web app compromise

In either case, the net result is that the attacker is able to move laterally through the network using stolen credentials. Since the credentials are those of an otherwise legitimate user, and since the attacker is accessing a system that the user has been granted access to, it can take weeks or months for the organization to detect that a successful attack has taken place. That is, it's difficult to distinguish the network activity of the attacker from the network activity of the users.

This problem is being tackled by the IT security industry on multiple fronts, including investment in machine learning-based monitoring and in broader support for multifactor authentication in the cloud. However, while monitoring is important, current state of the art is such that security event notification and incident response still take more time than is required by the typical attacker to achieve some sort of damaging data theft or reconnaissance.

Similarly, multifactor authentication is a must, but the devil is in the details. Many of the most common industry standard security protocols, such as OAuth and Kerberos, rely on session state artifacts (sometimes called tickets or tokens) that remain in computer memory after a user has been authenticated. Even if a multifactor credential was enforced for the initial authentication, the artifact can be used to gain access to network services for several hours thereafter. Attack tools look for those artifacts and use them to authenticate to other systems (each with its own cache of user authentication artifacts; this is why attacks can spread so quickly and easily).

Therefore, further investment is needed in authentication schemes that can enforce the use of a non-exportable credential for every connection attempt.

Hardware Protection for Devices and Clouds
The purpose of the new, open-source, HardwareProtectedSsh project is to demonstrate a new approach for preventing the electronic theft of high-privilege network account credentials. High-privilege users include system administrators, DevOps, and some service accounts. This project demonstrates security hardening by way of the popular authentication protocol, Secure Shell (SSH), as well as a widely available hardware-based cryptographic engine, the Trusted Platform Module (TPM).

In summary, by delivering cutting-edge enterprise security using a capability that most organizations have already paid, this approach makes for a great return on investment.

Why SSH?
SSH is a great candidate for this work because it:

  • Is widely used by DevOps in cloud scenarios.
  • Is flexible, in particular because of its ability to tunnel other protocols and application traffic. Security improvements to SSH offer great bang for the buck as compared to the investment of integration effort on other protocols.
  • Via the SSH-2 standard, supports user authentication based on the RSA cryptosystem and SHA-2 cryptographic hash algorithm. Both algorithms are also supported by the TPM 2.0 standard.
  • Enforces possession of a trusted user private key during each connection attempt.
  • Allows extensibility in the form of PKCS#11 cryptographic modules for private key storage.
  • Is multi-platform.
  • Is open-source.

Why TPM 2.0?
The TPM standard offers several notable capabilities in a way that is impractical achieve with other mass-market technologies. This unique combination of capabilities includes:

  • TPMs are built into the motherboard (or, alternately, System on a Chip, or SOC) itself. No additional hardware must be purchased, distributed, and managed.
  • TPMs come from the manufacturer pre-configured with a tamper-resistant cryptographic identity, key storage, and crypto algorithm engine. Among other benefits, this allows a zero-touch bootstrapping of trust, especially desirable in Bring Your Own Device (BYOD) environments.
  • TPM platform attestation is integrated into most PC firmware, as well as into many of the latest single-board computers. This combination of (UEFI based) Secure Boot and Measured Boot allows assertions to be made about whether a computer is running a trusted boot loader and operating system.
  • TPM platform attestation is natively supported by Windows and Linux. This allows assertions to be made about whether a computer is running a trusted configuration of the operating system and kernel drivers/modules.
  • TPMs can be remotely identified and queried using cryptographic challenge-response. This allows a trusted server to authenticate and interrogate user hardware (for example, over the internet) with much higher assurance than is afforded by existing configuration management tools, which ignore the threat of policy drift, and by existing Identity and Access Management solutions, which ignore the threat of computer credential theft.

Finally, the TPM cryptographic key storage engine and integrates naturally into common Public Key Infrastructure (PKI) use cases. However, there has remained a gap in middleware (i.e., the software that glues things together) support, especially on Linux. That gap has made the above high-security capabilities of TPM difficult to achieve in practice.

Architecture and Data Flow
The following diagram shows the principal software components involved in completing platform attestation, TPM key sealing, and a successful SSH connection using HardwareProtectedSsh.


The following sequence of steps refers to the diagram above.

  1. For initial host registration, platform attestation, and key creation, the user runs the CliTst program. In a production environment, this procedure could be scripted to ensure that every qualified user and computer gets a trusted TPM key.
  2. For demonstration purposes, the ssh-keygen program is used to export the TPM user public key from The key must then be manually added to the user SSH known_hosts file on the server (in this case, since SSH is a peer-to-peer protocol, ?server? means whatever computers are going to enforce the use of remote platform attestation and sealed keys).

    • In production, this could be automated for each user by instead pulling the public keys from the Attestation Service database.
    • Alternatively, SSHD could be extended to dynamically lookup public keys via a REST call to the AS in response to every connection attempt.

    • As a third option, certificates could be used, with a specific Certificate Authority (CA) and/or certificate policy OID designated for issuance to attested keys.

  3. The user initiates connections using ssh (i.e., and the PKCS#11 module). The previous steps ensure that the connection will only be successful if a known-good TPM key is being used on a host that is booted in a known-good configuration.

Get Your Hands Dirty
Details on performing the above steps in a lab environment are provided in the blog post Implementing Platform Protection for Linux (skim the first half, which mostly duplicates the above).

Keep in touch


Just for laughs

JW Secure Informer cartoon

Quote of the month

The possession of knowledge does not kill the sense of wonder and mystery. There is always more mystery.
- Anais Nin -

Thank you for reading the JW Secure Informer

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.