Security best practices

Overview

Proper security implementation is critical when integrating Guardian into your medical devices. Follow these best practices to ensure Guardian file assets are properly protected and your device maintains security throughout its lifecycle.

Guardian file asset security

Guardian uses three distinct groups of file assets, each with different security requirements:

• System files (formerly known as Preloaded files (PLF): These are the foundational files for your system. They must be loaded during manufacturing or signed software updates. They should always be write-protected and never updated directly.

• Provisioning package (formerly known as Initial provisioning files (IPF): This contains the bootstrap files for initial device setup, and is used for first-time device provisioning. These are a package of "marginally trusted" files that should only be distributed in controlled environments, preferably loaded during manufacturing and removed immediately after provisioning.

• Device files (formerly known as Provisioned files (PF): These contain the unique identity and credentials for each device, and are generated or retrieved during the provisioning process.

TPM requirements

Guardian does not require a Trusted Platform Module (TPM), though TPMs can be used for additional security when available.

Certificate formats

Guardian supports both standard X.509 certificates and Medcrypt proprietary certificates that are optimized for devices with memory constraints. The certificates you extract are normal X.509 certificates with standard expiration dates that can be inspected normally.

File recovery scenarios

The impact of losing Guardian files depends on which files are lost and when:

• During development: You can regenerate keys and start over at any time before infrastructure involvement.

• After initial upload: Your .mcpi and .mcpr files must remain intact. Loss of .mcpr before provisioning completion means restarting the process.

• After successful provisioning: Your .mcpi file must remain intact. A .mcp file can be retrieved by re-submitting the same .mcpr file.

Critical: Loss of a .mcpi file at any time makes the keys and provisioned components unusable.

Disk encryption

The purpose of disk encryption is for at-rest protection of file assets. Suitable methods for encrypting the disk should make use of an encryption key that is separately protected at rest (for example with a TPM).

Write protection

As root

For devices where processes accessing Guardian file assets run as root, write protection can either be achieved with file attributes (if using a compatible file system/OS) or with read-only mounting of the disk. With either approach, the file assets should be owned by root (and have permissions u-w,g-w,o-w).

As non-root

For devices where processes accessing Guardian file assets do not run as root, write protection can be achieved by having system files be owned by root with file permissions u-w,g-w,o-w (and optionally using file attributes or read-only mounting). Since provisioning package and device files must be writable in some scenarios, they should be owned and written with a special "provisioning user" (and have permissions u+w,g-w,o-w).

Read protection

As root

For devices where processes accessing Guardian file assets run as root, read protection can be achieved by setting file assets to have file permissions u-r,g-r,o-r.

As non-root

For devices where processes accessing Guardian file assets do not run as root, read protection can be achieved by creating a special "guardian-asset" group for the file assets to reside and setting file assets to have file permissions u+r,g+r,o-r. Processes needing to access these file assets must then be executed by a user that is in this group.

Writing file assets (provisioning)

Initial provisioning of a device is straightforward with device files being written to an appropriate path (and preferably the provisioning package being erased).

During reprovisioning, however, there will exist two sets of device files: the active set and the new set being generated. Particular care must be taken not to overwrite the active set during the provisioning process, thus usually necessitating that some sort of swapping strategy be employed (such as using symbolic links, environment variables, or remounting disks).

Additional device security best practices

Ensuring the security of keys is paramount, and they must be stored in memory areas immune to data exfiltration through methods like JTAG or similar techniques. It is crucial that private keys remain within the device and are not transferred off said device at any stage of its lifecycle.

Provisioning security considerations

During initial provisioning, write the device files to appropriate paths and erase the provisioning package files immediately. For reprovisioning, use a swapping strategy (symbolic links, environment variables, or disk remounting) to avoid overwriting active files while generating new sets.

Device security fundamentals

Store keys in memory areas immune to data exfiltration through JTAG or similar methods. Private keys must never leave the device at any stage of its lifecycle. Implement proper access controls and monitoring to detect unauthorized access attempts.