The Zymkey App Utils library provides an API which allows user space applications to incorporate Zymkey’s cryptographic features, including:
In addition, the Zymkey App Utils library provides interfaces for administrative functions, such as:
Some of the interfaces can take a filename as an argument. The following rules must be observed when using these interfaces:
zymbit must be added to the group that has permissions for the destination directory path and/or existing file.
zymbit must be added to the group that has permissions for the source directory path and/or existing file.
This feature is useful when the default host random number generator is suspected of having cryptographic weakness. It can also be used to supplement existing random number generation sources. Zymkey bases its random number generation on an internal TRNG (True Random Number Generator) and performs well under Fourmilab’s
Zymkey includes a feature, called Data Locking. This feature is essentially an AES encryption of the data block followed by an ECDSA signature trailer.
In addition to a unique ECDSA private/public key pair, each Zymkey has two unique AES keys that are programmed at the factory.
Each Zymkey comes out of the factory with three (Zymkey 4i/HSM4) or 12 (HSM6) unique ECDSA private/public key pairs. These private keys are randomly programmed within hardware at the time of manufacture and never exported. In fact, Zymbit doesn’t even know what the value of the private keys are.
There are three ECDSA operations available:
The Zymkey has an LED which can be turned on, off or flashed at an interval.
For Zymkeys with an i2c interface, the base address can be changed to work around addressing conflicts. The default address is
0x30, but can be changed in the ranges
0x30 - 0x37 and
0x60 - 0x67.
The Zymkey has an accelerometer which can perform tap detection. The sensitivity of the tap detection is configurable.
Currently, C, C++ and Python are supported.
Before a Zymkey can be effectively used on a host computer, it must be “bound” to it. Binding is a process where a “fingerprint” is made which is composed of the host computer and its SD card serial numbers as well as the Zymkey serial number. If the host computer or SD card is changed from the time of binding, the Zymkey will refuse to accept commands.
To learn more about binding your zymkey, go to the Zymbit Community “Getting Started” page for your Zymkey model (e.g. Getting Started with ZYMKEY).
Unlike Zymkey, HSM4 does not have a physical lock tab that is cut to lock the host binding. Instead, it has a software API for locking the binding to the host. See the soft bind lock API description for more information.
See “HSM4: Soft Bind Lock” above.
ECDH with some Key Derivation Functions (KDFs) is available. The available KDFs include:
In addition to NIST P-256 which is available on Zymkey and HSM4, the Koblitz 256 bit curve is available as well.
HSM6 now has 12 factory pre-configured NIST P-256 key slots and 512 key pairs for generated key pair and digital wallet allocation for NIST P-256 or Koblitz 256. All of these key slots can be used for ECDSA as well as ECDH operations. It is also possible to remove the keys in the 512 key pair store and also prohibit public key export.
128 public key slots are available to form a public key store for storing foreign party public keys. Like the 512 key pair store, public keys can be removed and prohibited from export.
HSM6 provides APIs which allow the creation of 1 or more digital wallets per BIP 32/39/44. The number of master seeds and child nodes is only limited by the number of key pairs provided for in the 512 byte key pair store. The BIP 39 feature provides the mnemonic sentence using the 2048 word English dictionary.
The HSM6 has APIs for reading the battery voltage as well as monitoring policies for taking action if certain thresholds are exceeded.
The Battery Monitoring feature provides for 1 of 2 actions if the battery voltage below specified threshold (settable from 2.5V or lower via API).
The Temperature Monitoring feature provides protection from attacks that are based on manipulation of temperature (e.g. memory freeze attacks). If invoked, the system may be configured to destroy keys if temperature thresholds are exceeded.