...
TBC No particular info in VIRTIO on this?
4.x Cryptography
4.x.x Random Number Generation
Random number generation is typically created by a combination of a true-random and pseudo-random implementations. A pseudo-random generation algorithm is implemented in software. "True" random values may be acquired by a hardware-assisted device, or a hardware (noise) device may be used to acquire a random seed which is then further used by a pseudo-random algorithm.
Requirement:
- The virtual platform SHALL provide VMs with access to a hardware-assisted high quality random number generator through the operating system's preferred interface.
(/dev/random device on Linux) - TODO, improve this:
The virtual platform should describe a security analysis of how to avoid any type of side-band analysis of the random number generation.
* The Hypervisor MUST offer at least one good entropy source accessible from the guest
* The entropy source SHOULD be implement using virtio-entropy according to VIRTIO TBD
* To be specific, it is required that what is received from the implementation of virtio-entropy must contain only entropy and never the result of a pseudo random generator.
Discussion:
Crypt device has been added to VIRTIO (crypto accelerator for ciphers, hashes, MACs, AEAD)
Sharing of crypto accelerators. On ARM they are often they are only accessible from TrustZone, and also stateful as opposed to stateless. Both of these things make sharing difficult.
Usable for filesystem encryption? Although CPU might be just as performant.
virtio-entropy (called virtio-rng inside Linux implementation) is preferred because it's a simple and cross-platform interface to deal with.
Some hardware implements only one RNG in the system and it is in TrustZone. It is inconvenient to call APIs into TrustZone in order to get a value that could just be read from the hardware but on those platforms it is the only choice. While it would possible to implement virtio-entropy via this workaround, it is more convenient to make direct calls to TrustZone.
TEE access
Discussion:
Access to TrustZone and equivalent functions SHOULD work in the exact same way as for a native system using the standard access methods (SMC
calls on ARM, equivalent on Intel). Another option used on some Intel systems is to run OPTEE instances, one per guest. The rationale for this is that implementations that have been carefully crafted for security (e.g. Multimedi DRM) are unlikely to be rewritten only to support virtualization.
Requirement:
* Access to TrustZone and equivalent functions MUST work in the exact same way as for a native system using the standard access methods (SMC calls on ARM, equivalent on Intel).
RPMB
Discussion
Note: Virtual rpmb recently proposed on VIRTIO mailing list (from Intel)
Different guests need their own unique Strictly Monotonic Counters. It's not expected for counters to increase by more than one, which could happen if more than one guest share the same mechanism.
Requirements
* If a system requires replay protection, it MUST be implement according to virtio-rpmb as specified in [VIRTIO-future]
Cryptography acceleration
Requirement
* If the hardware platform implements crypto acceleration, then the virtual platform MUST implement virtio-crypto as specified in chapter 5.9 in [VIRTIO]
Discussion
The implementation consideration is analogous to the discussion on RNGs. On some hardware these are offered only within TrustZone and in addition the hardware implementation is stateful. It ought to be possible to implement virtio-crypto also by delegation into TrustZone and therefore we require it also on such platforms.
N.B. Some guest implementations may still choose to access these features via calling into TrustZone implementations directly.
TODO: Please consider if this should be a MUST or a weaker requirement.
5. Supplemental Virtual Device categories
...
