[svsm-devel] Questions about crypto support
Claudio Carvalho
cclaudio at linux.ibm.com
Tue Sep 26 05:38:54 CEST 2023
On Fri, 2023-09-22 at 21:57 -0700, Dionna Amalie Glaze wrote:
> 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.
We have used FIPS 140 certification as one criterion to choose between crypto
libraries and approaches. However, multiple questions popped up on how difficult
would be to certify OpenSSL. So I added this question.
The aspect we started to discuss is if the OpenSSL should be built as a static
or shared library. If we are concerned about FIPS 140, the recommendation is to
use an OpenSSL version that has been FIPS validated, such as [1].
[1] says that the OpenSSL FIPS provider is a shared library (fips.so). IIUC, it
would be complicated to support a Linux shared library in the SVSM. On the other
hand, certifying any static crypto library would also be complicated.
Other aspects about FIPS 140:
- The same problem also exists for OVMF since it also builds its own crypto
library (OpenSSL).
- Even if we use a FIPS validated crypto, we still need to make sure that the
consumers will support it. IIUC, the Microsoft TPM implementation does not
support a FIPS validated OpenSSL.
My impression is that FIPS 140 is a complicated problem when it comes to
firmware and it seems too big to be considered now. I would like to hear what
you guys think about that and if CPL0 should have it's own crypto (e.g.
RustCrypto) in order to simplify the design. At the moment, the only crypto
requirement we have for CPL0 code is AES_GCM, which is required by the
attestation report feature.
[1] - Latest FIPS validated OpenSSL -
https://github.com/openssl/openssl/blob/openssl-3.0.8/README-FIPS.md
>
> > 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.
>
Jorg mentioned that IPC could be an option for communication between CPL3
modules, but then James mentioned that crypto operations may not perform well
over IPC. I added this question to check if we need to revisit this.
> >
> > 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.
Libcrt is a libc implementation we created for the SVSM-vTPM proof-of-concept we
developed some time ago [2]. It is subset of musl + some OVMF stubs that we put
together to easily build OpenSSL and the Microsoft TPM. However, with CPL3
support, we may want to have more complete libc implementation.
[2] Libcrt - https://github.com/svsm-vtpm/libcrt
Claudio
>
> > --
> > 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)
More information about the Svsm-devel
mailing list