Welcome 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.
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
- 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
Therefore, further investment is needed in authentication schemes that can
enforce the use of a non-exportable credential for every connection attempt.
Protection for Devices and Clouds
The purpose of the new, open-source,
project is to demonstrate a new approach for preventing the electronic theft
of high-privilege network account credentials. High-privilege users include
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.
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
- Allows extensibility in the form of PKCS#11 cryptographic modules
for private key storage.
- Is multi-platform.
- Is open-source.
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
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
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.
and Data Flow
The following diagram shows the principal software components involved in
completing platform attestation, TPM key sealing, and a successful SSH connection
The following sequence of steps refers to the diagram above.
- 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.
- For demonstration purposes, the
ssh-keygen program is used to export the TPM
user public key from
libp11platformattestation-x64.so. 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
- 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
- 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.
- The user initiates connections using
ssh (i.e., and the libp11platformattestation-x64.so 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
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).