[svsm-devel] Questions about crypto support

[Dionna Amalie Glaze]

On Fri, Sep 22, 2023 at 2:04 PM Claudio Carvalho <cclaudio at linux.ibm.com> wrote:
>
> Hi everybody,
>
> In the last SVSM meeting we started to discuss some design questions related to
> crypto support and I mentioned that I could open a github issue for us to
> continue the discussion. However, I have the impression that mailing lists have
> worked better for discussions. Let me know if this is not the case.
>
> Since the crypto support questions applies directly to the context of vTPM and
> attestation, I also added a block diagram below to help us visualize the big
> picture.
>
> Feel free to add new questions or information that you find relevant.
>
> Thanks,
> Claudio
>
>
> Questions
> ---------

Forgive me if my answers wrt CPL0 and CPL3 are full of misconceptions
about how SVSM plans to implement this support. I'm quite new here.

>
> Q1) FIPS 140 certification. Should we consider OpenSSL as a static or shared
> library?
>

Is there a plan for dynamic linking support for shared libraries to be
possible in SVSM? I would think everything is going to be statically
linked, loaded as part of the boot image, and not even
position-independent.

> Q2) How should we handle build dependencies between CPL3 modules? E.g. the vTPM
> (Microsoft TPM impl.) build depends on the OpenSSL library.
>

Different CPL3 modules will be have their own CR3 values, right?
Unless you develop an library envelope service to turn library calls
into RPCs across process boundaries, I would guess everything needs to
just be duplicated with static linking.

> Q3) What libc implementation should we use to build OpenSSL and other CPL3
> modules?
>
> Q4) Interface 1. How CPL0 code should communicate with CPL3 code?
>
> Q5) Interface 2. CPL0 to CPL3 communication may need to carry secrets (e.g.
> VMPCK0 key), how should we do that securely?
>

I think that whichever CPL3 module(s) that will handle VMPCK0 will
need to be hardcoded such that only specific vetted code is allowed to
have that data copied into its context. That code is trusted to manage
that key material correctly and destroy it after use. I wouldn't want
that access to be arbitrarily available.

> Q6) Interface 3. How a CPL3 module should communicate with other CPL3 modules?
> It may also need to carry secrets such as keys.
>

I don't expect a full VFS system to make shared memory a thing to
implement IPC. I would imagine that you would send messages to
different modules by handing a buffer and a module identifier to CPL0
to go deliver to that module's mailbox and return success, mailbox
full & try again later, or message too large.

>
> Appendix 1: vTPM and attestation as a use case
> ----------------------------------------------
>
>            .-------------.     .-------------.
>            |   Runtime   |     | Attestation |
>   -------->|  Protocols  |---->|   Report    |
>            '-------------'     '-------------'
>                   |                   |
>                   |                   v
>                   |            .------------.
>                   |            | Crypto API |-----.
>                   |            '------------'     v
>                   |                           .------.
>               Interface 1                     | ossl |
>                   |                           '------'
>                   |                               |
>           CPL0    |                          Interface 2
>       |-------------------------------------------|-------|
>           CPL3    |                               |
>                   |                               |
>                   v                               v
>            .------------.                    .---------.
>            |    vTPM    |                    | OpenSSL |
>            |   Module   |----Interface 3---->| Module  |
>            '------------'                    '---------'
>
>
> A1-1) CPL0: Runtime Protocols
> -----------------------------
>
> SVSM protocols described in the SVSM spec:
> - Core
> - Attestation
> - vTPM
>
> A1-2) CPL0: Attestation Report
> ------------------------------
>
> Implements the attestation report feature. When a VMPL0 attestation report is
> requested, the request needs to be encrypted/decrypted with the VMPCK0 key
> using AES-GCM.
>
> A1-3) CPL0: Crypto API
> ----------------------
>
> SVSM kernel interface (Rust trait) that abstracts the crypto module running in
> CPL3.
>
> Example in pseudo-code:
>
> aes_gcm_encrypt(key, iv, aad, cleartext, ciphertext, authtag)
> aes_gcm_decrypt(key, iv, aad, ciphertext, authtag, cleartext)
>
> A1-4) CPL0: ossl
> ----------------
>
> Crypto API implementation (wrappers) for OpenSSL.
>
> A1-5) CPL3: vTPM Module
> -----------------------
>
> Microsoft TPM 2.0 reference (ms-tpm-20-ref) implementation; only the TPM
> Simulator interface is exported.
>
> The ms-tpm-20-ref build requires OpenSSL (or WolfSSL).
>
> A1-6) CPL3: OpenSSL Module
> --------------------------
>

Big organizations will have their pet crypto libraries they'll prefer.
We'll need dedicated maintainers from each one if we're going to
strive for compatibility, or we run the risk of forks and separately
vendored binaries.

I'm very interested what people are thinking in terms of binary
distributions and co-endorsement of verified builds, since signatures
are so much easier to work with operationally than always verifying an
attestation's measurement back through a transparent build process.

WRT source -> measurement transparency, Google has been working on
slsa.dev for build security, provenance tracking and verifiable build
artifacts, and Project Oak has a transparent release project to tie
sources + toolchain container through to the slsa artifact that gets
signed and added to the sigstore.dev repository of build artifacts.
A fork is a big deal due to the downstream effects that has on
auditors of this code as it flows through a transparency toolchain.
We'll need a approach transparently built binaries of the favored
varieties (crypto library x,y,z crossed with TPM simulator x,yz) as
"public good" work, further with the community's agreement about which
toolchain containers are trustworthy. Google Cloud build doesn't quite
hit the SLSA L3 target we'd like with their container marketplace, so
I'm still running that one down.

> OpenSSL library built to run in the restricted SVSM environment. Summary of the
> build steps we have used (inspired on how OVMF builds OpenSSL):
>
> - create a svsm_openssl.config that sets some compiler flags and inherited
>   configs.
> - disable crypto modules not needed

>From my understanding of FIPS 140-2 certification, the process
involves a 100% audit of all of the machine code, and for
organizations like Google, it's best to not mess with the linked
object. We're locked into a 2MiB blob for all crypto operations done
in any regulated workload. This bloat-shedding is typically not worth
the annual O($300,000) cost of recertification.

> - reduce memory footprint
> - link it against the libcrt library, which is a small libc we crafted to build
>   OpenSSL (libcrt) and the Microsoft TPM.

I'm not particularly familiar with libcrt. Do you have a link to the
project? How healthy is it?
There's also the nanolibc project Google has for similar situations
(which I'm not suggesting we use. It has exactly 1 commit by Bill
Cox–solid guy working in sealed computing, but busy).
I'm not saying this for tribal reasons, more that I'm not sure who's
responsible for maintenance of all these dependencies, their
reputation or level of qualification, and that makes the enterprise
tech leaders I need to discuss risks to... itchy.

> --
> Svsm-devel mailing list
> Svsm-devel at coconut-svsm.dev
> https://mail.8bytes.org/cgi-bin/mailman/listinfo/svsm-devel



--
-Dionna Glaze, PhD (she/her)