The YubiHSM 2 is a great solution for customers looking for a low-cost and lightweight approach to hardware-based password or certificate management, but may be a little perplexing to implement due to its alternative approach versus traditional means. This short article will attempt to discuss some of the top practical considerations to help navigate or alleviate the common concerns.

So, what’s the source of the confusion? The most widely accepted but legacy enterprise approach is an ultra high-end hardware security module (HSM), often costing tens (if not hundreds) of thousands of dollars, that can best be described as a physical behemoth. Customers find, however, that due to the nature of a traditional HSM, physically securing the device is often straightforward, such as by mounting using a server room or datacenter rack, but even virtually, since they’ve grown accustomed to the existing processes to lockdown network access for remote malicious activity.

In stark contrast, the revolutionary device from Yubico is the size of a literal fingernail and is purposely designed to be accessed and managed using a variety of approaches including the proprietary yubihsm-connector, PKCS #11 or a Key Storage Provider (KSP). The multitude of options makes the YubiHSM 2 extremely flexible, but it's important to highlight that users always retain the option to disable network access entirely and manage it the traditional way as well. Let’s first explore the physical implementation considerations and then move onto the virtual ones, to ensure the most effective utilisation of the YubiHSM 2 for your deployment.

Figure 1: The YubiHSM 2 connection stack

Physical Deployment Considerations

The YubiHSM 2 (as with all Yubico devices with the notable exception of the YubiKey 5C Nano) possesses a keyring hole which can be threaded to physically secure them to the host they are plugged into for extra security, such as by a wire or cable. The concept is similar to that of the Kensington Security Slot for example, often used to secure laptops to hard surfaces.

This approach can prevent or at least deter the removal of a YubiHSM 2, and the threaded fixture can even be welded onto the server chassis for maximum protection. The obvious trade-off is the extra effort required to remove the device for legitimate reasons later on, so that is certainly something to keep in mind.

Threading is not the only way to secure a YubiHSM 2, however, as it is also worth mentioning that there are a number of servers out there which already have internal USB ports directly mounted onto the motherboard and is certainly a feature that can be requested from server hardware vendors. Check if this is applicable in the first instance, as it is easily the path of least resistance, since the YubiHSM 2 can be implemented inside a host chassis without then requiring additional physical security measures.

Figure 2: A server with an internal USB-A mounted port

But even in scenarios where it may not be possible or make sense to physically secure the device to a workstation or server, there are still a substantial range of protocol level security controls available to mitigate the risk of physical removal or theft. This could include physical on-premise security, surveillance and personnel entry restrictions, and in fact, the YubiHSM 2 is currently commonly deployed in many such remote and untrusted environments. Explore what other tools are available to your specific circumstances and take the appropriate actions to safeguard the YubiHSM 2 as you would with any other valuable piece of hardware.

Virtual Deployment Considerations

Because the YubiHSM 2 may be accessed remotely, it is prudent to consider and address any theoretical virtual or network attack vectors. It should firstly be stated that communications with the device are always performed over sessions. Each session is end-to-end encrypted based on the global standard Secure Channel Protocol (SCP03), which is a way of transferring data that is both resistant to overhearing and tampering, and can even be configured to transmit over HTTPS for added security. Furthermore, an authentication key is always required before a session can be established, which comprises two AES keys that are derived from the PBKDF2 algorithm.

For enterprises that choose not to pursue the YubiKey as a means to secure the authentication key specifically, it cannot be overstated that whichever means is implemented, it not be easily breachable. If your enterprise has chosen the YubiHSM 2 approach for hardware-based password and certificate management of critical assets, it seems counterintuitive to then store the associated authentication key in software.

Another critical point to highlight is that sensitive and confidential data can never leave the Common Criteria EAL 6+ secure element of the YubiHSM 2 (or any other Yubico product for that matter). So even if unauthorised access were obtained, modifications could be made to the logical contents (i.e. delete or add new objects) but existing objects would still be unobtainable. Those objects may be exported under Wrap to create backups, however, but even this mechanic uses an additional encryption technique which still does not expose the existing objects outside of the device.

Figure 3: Backup is essential to enterprise data management

On the topic of backups, a strong recommendation is to create at least one backup of any deployed YubiHSM 2, just in case it is ever needed in the future. Obviously remember to physically secure the backup(s) just as diligently as the original - such as in a safe deposit box - as a chain is only as strong as its weakest link.

One extra measure that is highly advisable, is to create firewall or network traffic rules to limit which hosts on the network can access the server to which the physical device has been inserted. The aim is to narrow the range from which a network attack could potentially take place, adding an additional layer of security.

Finally, attestation is a utility option which can bolster any implementation further, by ensuring the identity and authenticity of the YubiHSM 2 itself, in addition to any exported public asymmetric keys. The Yubico root certificate and the sub CA-certificate may be used to quickly identify malicious attempts to subvert or break the chain of trust, and the pre-loaded certificate can even be used to sign a public asymmetric key for verification. Attestation is simply another way to tighten an already secure implementation, so it’s important to investigate if and how it may be applied to your specific circumstances in conjunction with the previously discussed measures.

Figure 4: An example YubiHSM 2 certificate chain

If implemented correctly, and taking into account the above considerations for your enterprise, the YubiHSM 2 remains a relatively inexpensive and impeccably secure alternative to other solutions on the market while retaining the Yubico gold standard. Be sure to visit the YubiHSM 2 developer site to learn more about the YubiHSM 2 capabilities.

Yubico can work with you to provide a solution that meets your specific security requirements.  Please contact your Yubico sales representative or request someone to contact you to discuss your specific implementation needs.