This content details the cryptographic capabilities of Calyptra, focusing on its role in establishing a root of trust, managing device identity and measurements, and providing cryptographic acceleration services to the System on Chip (SoC) and Microcontroller Unit (MCU), with an emphasis on post-quantum cryptography readiness.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
Uh, right. So, we're going to talk about
cryptography in Cliptra. Cryptography.
>> Turn your mic on, please.
>> I thought I did. My mic is on.
>> It's on.
>> I can hear an echo
>> testing. Yeah.
>> Yeah. Yeah. Do I need to like adjust?
>> I'm good. Okay. Uh, all right.
Cryptography, my favorite topic. Uh, so
I'm Christopher from Microsoft. This is
Jeff Google. Um we just wanted to talk a
little bit about some of the fun
cryptography that's used in Calyptra as
well as exposed by Calyptra to be used
by the SOC. Um so yeah so uh we'll talk
a little bit about like the identity
pieces of the root of trust as well as
measurements uh and then also some of
the pieces that are used in you know
exposed as mailbox commands and
cryptographic services and how this all
integrates into postquantum. Um did you
want to start? >> Sure.
>> Sure.
All right. So, it all starts with uh two
secrets in Calyptia. First, there's a UDS
UDS
uh 384 384 bits wide in 1.x. We bumped
up to 512 and 2.x
um burned at manufacturing time and then
kept alone except until you want to end
of life the device and zeroize it. Field
entropy is not burned at manufacturing
time. It is burned in the field. Hence
the name uh 256 bits burned out
manufacturing. The reason for burning it
later is so that the device can traverse
a risky supply chain without having
those secrets burned in so that an
adversary in the middle that extracts
the secrets won't get at the field
entropy that only comes in when it
Uh we derive additional secrets off of
these secrets uh CDIs using the dice
hierarchy. So using HMAC counter KDFs,
it's all very NIST approved. Um the fact
that we're deriving asymmetric keys off
of these is maybe a little bit less
formalized right now, but we hope that's
going to be straightened up real soon.
So from UDS, we derive IDEV ID, fix it
manufacturing time, and we stratify
this. We then have field entropy derive
the next layer. And this is so that when
you blow field entropy, you haven't
damaged your dice chain. It still roots
back to the manufacturing certificate.
So that uh if you do not decide you
don't want to care about whether field
entry was blown or not, you can always
just walk back to the manufacturing.
And then from LDE ID, we go to FMC
alias, which brings in FMC measurements
and other configuration uh values. and
then runtime and then DP contexts which
provide measurements for other things
Uh each of these keys gets certificates
where you can then encode uh the
measurements that contributed to their
derivation which gives you strong
cryptographic binding of what device am
I talking to, what is its configuration
and what code is it running.
to uh deal with postquantum, we've
elected to create separate certificate
chains, not hybridized certificates, but
different parallel ones. Um, and if you
want a hybrid assurance, you could do a
couple of independent attestations using
each of these algorithms. Um, if you're
here is a diagram. There is going to be
a quiz on this later sort of one. Please
look closely at it.
Just kidding. Um, this you can find in
the specification. This kind of just
illustrates the different components of
Uh, measurements. So, we have Calyptra's
own measurements captured into its own
native dice chain and we mentioned DP uh
that can hold measurements of other
components. In caliper 2.x, X. We also have
have
direct visibility into the measurements
of firmware that's actually loaded into
the MCU, which lets you bootstrap trust
that way. And we hold not only DP
context, but also 32 uh PCRs that are
essentially rolling hashes where you can
deposit those measurements. Each PCR is
3 384 bits wide. And there's a mailbox
command that lets you get the current
value of each of those PCRs assigned by
the FMC alias key. Here
are some use cases or uses that we've uh
carved out for these different PCRs. Um
so the FMC measurements and ramen
configuration is in PCR0 and one. Uh
you'll notice that some are labeled
current and some labeled cumulative. So
if you want a bit more of an easier to
digest what am I currently working with
you could look at the current PCRs and
these get reset every time you hitlessly
or runtime update Caliptra. If you want
a complete log of every change that ever
happened to Caliptra since cold boot,
you would look at the cumulative
registers which do not get reset across
Over to you. >> Yeah.
>> Yeah.
All right, cool. So that was the uh sort
of identity pieces and then uh as
Cliptra has evolved, so it was
originally in 1.x extremely focused just
on identity and measurements. So it only
really had exposed hardware, you know,
that did things like Shaw, HMAC, ECDSA,
and LMS. Um, and this is only kind of
partially available outside of Calyptra
Core. These were services more or less
reserved for Calyptra itself and a
little bit exposed to the SOC to do
measurements maybe with its Shaw
accelerator 2.0 built that out and
expanded it so that there's a bunch more
cryptographic services that Kipure
provides to its SOC and to MCU uh as
well. So notably AES, ECDH were added as
well as MLDDSA for postquantum. Uh and
then it expanded access a bit more to
the hardware and or to the SOC. I'll
discuss how we did that. And then 2.1 um
adds additional support for in
particular shake uh as a shake
accelerator for you know part of Shaw 3
uh MLEM AES DMA so that you can use uh
AES in a little bit more performant
manner uh as well as OCP lock uh which
we've talked a lot about. Um the way
we've now exposed that in 2.0 going
forward is through a system called the
cryptographic mailbox. So this allows
you to use Calyptra core as a
cryptographic accelerator and it
provides a like relatively orthogonal
set of APIs that can be used over its
mailbox to do cryptographic operations.
So it allows either MCU or the SOC or
both to use these services, generate keys,
keys,
use cryptography, and use all these nice
hardware engines that we're paying the
silicon price for. So we might as well
expose them as long as we can do so in a
safe manner. Uh so uh this also allows
additional services to be more easily
built by like a companion like the MCU.
So Kalypture core is meant to be very
tight and focused and so won't have an
implementation of say SPDM or PLDM which
are these much larger protocols and you
wouldn't want those necessarily in a
very small you know ROM and firmware. So
if but in order to implement those you
need a lot more stuff like you need AES
and you need key exchange and whatnot.
So that's where the cryptographic
mailbox comes in. Uh I'm going to come
back to this slide. Uh so the first
question you should always ask whenever
you have any sort of new cryptographic
services is how are the keys managed? So
like that's great and all how do keys
get in? How do keys get out? What's the
key story? Because you know kaliptra has
its own keys. certainly, but how am I
going to use keys with Calyptra? Uh, so
Calyptra like fundamentally has very
minimal storage and no real persistent
storage. So it's not going to
necessarily store keys for you. But what
it does is it has the ability to uh
essentially not quite wrap keys, but
generate keys or import keys and provide
them in a wrapped form that you then
provide later. Uh, and that's sort of
the heart of the mailbox system. So are
these CMKs, these cryptographic mailbox
keys. It's a 128 bytes or 1024 bits of
encrypted basically blob that you get
back from Calyptra and then you pass to
Calyptra to use and that holds your key
material with it. So this way Caliptra
doesn't have to keep all this key
material in it, but it can just generate
it, wrap it and send it back and you
provide it. you being the MCU or the SOC
can provide that blob back in to be used
uh but without requiring Calyptra
storing anything. Uh it's not true it
doesn't store anything. I guess I did
have it does store limited usage
information for specifically AES GCM
there. I think we mentioned earlier
there's this 2 to the 32 like 4 GBish
limit uh whenever you're doing anything
with AES GCM which is an annoyingly
small amount of usage. And so we do try
to keep track of how much each AES GCM
key is used just so that we don't hit
that limit because that keeping track of
that is required for FIPS. But other
than that limited storage space for
those usage counters, we don't store
anything in Calyptra. Uh it's all just
exported to the user who is then going
to use those mailbox commands. Um and
yeah, like I said, the CMKs have to be
used every time. uh internally this is
all done with AESGCM to wrap these uh
this key material and it looks sort of
like this. The left hand side is the
unencrypted structure. So this just has
usage information making sure you're not
using a CMK for a usage it's not meant
for. Making sure we understand the size
if there is a size difference if there
is a usage counter that's also kept
there and tracked uh and things like
that and as well as some other metadata.
uh and then there's also the encrypted
blob format uh which has enough
information more or less just so that
the cryptographic mailbox system can
decrypt that. So now I want to go back
to that other slide which was again how
do keys get in how do keys get out? So
there's a couple ways to get a key from
Calyptra. So Caliptra normally boots up
it's done booting how do I get a key in?
Well there are you can import a key. So
if you have say a durable key stored in
fuses or some flash or somewhere you can
import it into the cryptographic mailbox
system with an import command and it
will give you back a wrapped key that
can then be used for operations. Uh
there's also a derive functionality.
This allows you to derive additional
keys off of the IDEV and LDEV secrets.
So if you want a key that's stable
across reboot every time, uh you can say
I want to get a key that's derived off
of IDEV and we allow those uh to then be
returned as CMKs. And that way you get
you don't get the same CMK every time,
but you get the same inner key material
every time. Uh so the CMKs are always
ephemeral uh and they always get wiped
across reboots, but the inner key
material will be the same every time.
And so you can use it uh you can just
rederive the same key every time. And
then you know similarly you can use that
import functionality combined with the
random functionality uh to generate a
random key for instance.
Um so cryptographic mailbox commands
there's some for basically every
functionality within Calyptra that's
exposed AES in a bunch of modes. uh
ECDSA, MLDDSA, ECDH, uh Shaw is
supported in a streaming mode so that
you can stream data in uh HMAC and HKDF.
Uh and then now in 2.1 we're going to
have uh soon uh MLKM shake and AESDMA
commands as well. Uh I wanted to quickly
go over some atoms rich performance
because oh there's usually two questions
with any postquantum talk is uh you know
what's what's the performance like and
what's the space like can't really help
with the space but with performance it
was quite surprising to me at least at
how well it performs something like
between five and 46 times faster for
MLDDSA depending on which exact
operation uh compared to ECDSA. So
ECADSA the baseline was almost 2
milliseconds but we're talking you know
1/5 or 1/50th of that for MLDDSA
operations. So that's quite encouraging.
Uh MLKM has a pretty similar uh I think
performance difference. Uh it's even
more consistent though uh since the
rejection happens at a different stage.
So key gen is extremely fast and
encapsulation and decapsulation the
equivalent of those in ECDSA were would
okay there we go sorry about the
feedback. Uh so again there's still a
similar but actually even more like 50
to 100x performance improvement. Um so
uh the downside is that these have
problems with expansion. So whenever we
mask them to make them protect against
side channel attacks, we typically get a
much worse area overhead, something like
6x overhead for MLDDSA and MLEM as
opposed to ECDSA which doesn't have a
huge masking overhead.
So uh I think that covers most of it. As
always, uh we're clip is open source.
We're welcome to feedback and talking
about uh you know anything we want to
add or work on for the next versions,
>> So, if there's any questions, make your
>> Uh, yeah, I had a quick question. Um I
didn't see it in the road map earlier
but I was wondering if there is a plan
to increase the ability of Calyptra to
handle more measurements uh particularly
uh with regard to the stash measurement
um you know primitives if that's going
to be something like in 2.2 uh would be enhanced.
enhanced.
>> I think we do have plans on this. So, we
haven't officially announced that we're
doing this, but we've been talking
internally about increasing the number
of stash measurements allowed now that
we have we have a little bit more memory
in 2.0 and 2.1. Uh, and so we have I
don't know if we've settled on an exact
number. I think the number was something
like 8 or 16 initially and now I think
we are going to increase that, but I
don't want to make a promise on to how
much. Uh, but we are we are aware of
that limit and it's something we're
adding more flexibility to in the near future.
future.
>> Thanks. be helpful to hear like what
your requirements would be.
>> Right. Right. If you had to Yeah,
exactly. So,
>> yeah, I'm I'm Jordan. I work on Calyptra earlier.
earlier.
>> Yeah. I
>> What are you asking questions for?
>> I I think No, I don't have a question. I
have an answer.
>> Um, yes, we can increase the limit. I
mean, Calyptrahead does have limited
SRAM, so we have to be a little careful
about doing that. But yeah, I think my
biggest question to you or to this is
not the you're not the first person to
have asked this um is what's the use
case? Just cuz you can kind of explode
the number of measurements you make if
like you know if you're making
120 measurements of your SOC then the
question is like okay are we doing
something wrong? So I just want to make
sure that like as an industry we're
designing our measurement architectures
in a you know consistent way.
Yeah, I think the the limitation we did
very quickly was when we consider
>> you want to use the mic uh so everyone
can hear. >> Sorry.
>> Sorry.
>> Yeah. I mean we can also like I'm happy
to talk outside if if we want to move on.
on.
>> Yeah. Yeah.
>> Are there other questions?
>> Another minute if you want to use your
minute. So
>> is is there are there any other quick
questions before we wrap up? Uh I
unfortunately did not get a chance to
talk about all of the other fun
cryptography used internally in Caliptra
which I realized during uh the last few
talks like the life cycle controller and
the fuse controller has a lot of
interesting cryptography. There's
another shake uh engine in there for
instance for tokens. There's all sorts
of other fun things going on but only
have so much time. I focus mostly on
stuff exposed to users of Calyptra. So
uh but I'm happy to talk about any of
those pieces as well.
>> All right. Thanks a lot folks. Yeah,
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
