0:06 Welcome. My name is Samuel Smith. I'm the creator of the KERI suite of protocols.
0:15 And this video is a tutorial talking about KERI from a high level. KERI stands for
0:22 Key Event Receipt Infrastructure. It's been in development for several years now.
0:28 And you can think of it and as a secure identifier overlay as a trust spanning
0:34 layer for the internet. So, we're going to talk about what that means today. For
0:40 resources, you can go to the website KERI .one. Should be easy to remember. Look at
0:47 the resources page. There is an active KERI community with various standards and
0:54 specifications. You can find the code, which is is Apache 2 licensed at the Web
1:03 of Trust GitHub repo. The Trust Over IP Foundation, which is a member of the Linux
1:09 Foundation's decentralized trust organization, governs the specifications
1:16 for the relevant protocols. These are licensed using the Open Web Foundation
1:22 license, which is a freely licensed open specification license. And you can find
1:29 meetings there and there are a couple of links for that. The motivation for KERI
1:35 came from years of working with protocols. I started life as an academic, did a lot
1:42 of work with AI and autonomous vehicle systems back in the 90s. Started working
1:52 with protocols in the Internet of Things also back in the 90s. And later in my
1:59 career, started working on cloud-based automation systems and was confronted with
2:05 the problem that the internet did not have a really good security system. And if you
2:15 think about it, the internet has lots of problems today and they're getting worse.
2:21 And so this idea that the internet was broken in can be traced back to the fact
2:27 that the internet never had a security layer. If you look at the comparison of
2:32 the OSI model and the IP model, the layers where you do authentication are in the
2:39 presentation and session layers and the IP protocol doesn't have those layers. The
2:46 result is that instead we use bolt-on security systems or sometimes called
2:53 security overlays These are commonly known as domain name systems, certificate
2:59 authorities, openID connect, OAuth, various types of systems that provide
3:06 security. And that security is based on what was a good idea 20 or 30 years ago
3:15 when it was created, but now is no longer such a good idea. And so KERI is about
3:21 reimagining what the internet would look like if we had a security layer that
3:27 actually worked.
3:31 The idea can be traced back to something called a spanning layer. So, the internet
3:38 in its early days wasn't viewed by everyone as something that was going to be
3:45 universal. It was an experimental protocol. But very quickly, relatively
3:51 speaking, it dominated all of the other communication protocols and became the
3:57 dominant protocol for the whole world. And one of the analyses as to why that
4:07 happened is that the internet had a spanning layer and that spanning layer
4:13 made it possible for the internet protocol to grow in a way that allowed it to
4:22 subsume all the other protocols and provide all the services. And that what
4:25 that spanning layer in the internet is the IPv4 for, you know, IP version 4 and now
4:31 we have IPv6. But originally this is the diagram that was used to demonstrate that
4:38 there was something called a spanning layer. And if you think about it, it looks
4:42 like an hourglass and the waist of the hourglass is the IP layer. This is the
4:46 addressing layer. Everything above that layer uses the same address and everything
4:52 below that provides support for that addressing layer and that feature of the
4:57 spanning layer. And you can look at some of the papers that have been written about
5:01 that is reputed to be the reason one of the reasons the internet became so
5:08 successful as a protocol. The problem that we've had is that because the spanning
5:15 layer of the internet did not have any security built into it, it didn't have a
5:19 trust basis. What has happened is that we now have what I call platform lock trust.
5:25 In order to have trust, you have this IP spanning layer and then you have supports
5:30 for it. And then you have applications built on top of the spanning layer, but
5:34 they don't have trust in them. And then you bolt on trust above those. And so what
5:40 you get is trust domain based segmentation of the upper layers. And so you don't have
5:49 trust across those those walled gardens or columns above that. And so you don't have
6:00 trust that spans the internet. It just spans a given platform. So you get a
6:06 bifurcated internet trust map. There's no trust spanning layer in the current
6:11 internet. And you might think of this as like, you know, different platforms that
6:17 have different trust bases or, you know, and often trust is the identity system,
6:23 right? So you have a Facebook identity system and within Facebook you have trust
6:28 and on Google you have its identity systems and within Google you have trust
6:32 and you might have other platforms like blockchains that have trust within their
6:38 trust domain but they're not interoperable. You can't move trust
6:43 between those trust domains. So the basis of the spanning layer, there's a really
6:51 well-written paper that talks about the hourglass approach to building protocols
6:58 where you have a spanning layer. And so we feel that that's the right approach, but
7:03 we just need to have a trust spanning layer. And we don't want to reinvent a new
7:08 internet that would be ludicrous, but we want to allow the internet to remain the
7:16 internet, but add a spanning layer that allows trust. So there's not locked to
7:21 different platforms. And so our solution we call a waste and a neck is we have the
7:27 IP spanning layer, which is the waste, and then we add a trust spanning layer that is
7:31 the neck. And if all trust spanned applications use the same trust spanning
7:37 layer, then they'll have interoperability in terms of their trust. And so you can
7:41 still have platforms, you can still have all the protocols down below, but if you
7:46 want to have applications that span trust, where trust spans across the applications,
7:52 then we want to have a trust spanning layer. So that's the design goal of KERI.
7:56 So I've used the term trust basis or trust domain a lot. And so I just want to define
8:03 it so that you understand what I'm talking about. A trust basis is the set of trust
8:07 roots. And when we talk about systems design, we talk about things like roots of
8:11 trust, things that you can rely on that have certain well-defined properties. And
8:18 then based on those things, you can build other services and functions on top of
8:23 that. So we talk about a trust basis and then a trust domain is the ecosystems of
8:30 interactions that rely on a given trust basis. So for a trust spanning layer, we
8:36 would need to have everything above that rely on the trust basis that is the
8:43 spanning layer. And so KERI is about defining what that looks like. So, the
8:49 basic idea of KERI, and we'll go back into this in more detail, but the idea is that
8:57 we can define an identifier system security overlay. It's a new type of
9:01 overlay that acts as the trust spanning layer. So, you have infrastructure that
9:07 sits below the secure identifier overlay or the secure identity overlay. And then
9:14 you have a trust domain that sits above that. And the spanning layer is that
9:21 overlay. Now, when people look at KERI, often they look at it and it's difficult
9:26 to understand. And one of the reasons that KERI is difficult to understand is that we
9:31 call it the platypus of the identity space. And the reason for that is if you
9:35 look at the platypus, it's a very interesting animal. It's difficult to
9:40 classify because it has a unique combination of features not found
9:45 elsewhere in nature. or at least not in that combination. For example, because it
9:50 has milk, a platypus looks like a mammal, but it also lays eggs, so it looks like a
9:55 reptile. It has a bill, so it looks like a bird. It has electrolocation, so it looks
10:02 like a ray. And it has venom, so it looks like a snake. And so if you approach a
10:10 platypus from the mindset that every identity system has to look like a mammal,
10:15 it will be confusing. Or if you approach it from any of the other viewpoints. So
10:23 KERI is best approached from the fact that it is truly unique in many important ways.
10:30 So KERI deconstructs what many people are familiar with in identity and security
10:37 systems to create a novel combination of properties that solve what we call the
10:43 universal secure attribution problem. And we'll go into that in more detail. If you
10:47 think about a system design trade space, you can have lots of puzzle pieces that
10:52 you can put together and there's lots that one can select from. But KERI carefully
10:57 selected a subset and left certain things out that it didn't need so that it got the
11:04 properties that it did need to solve the problem and the problem of a trust
11:10 spanning layer requires solving the problem of universal secure attribution.
11:15 And if you think about it, if I want a trust spanning layer, then I have to be
11:21 able to do something universally. So KERI is a well-fit-together puzzle where the
11:28 pieces are carefully designed to match that trade space. So let's step back a
11:35 little bit because we've talked about the internet. Let's talk about each individual
11:41 person. Why should I care about having a trust spanning layer on the internet. Why
11:47 should it matter to me? The fundamental idea that KERI tries to solve is to enable
11:54 entities, both natural persons and legal entities of all types, to retake control
12:01 of our data and the value of that data. And if you think about the internet and
12:07 how it's evolved, most of the value of the data on the internet is not controlled by
12:11 the individuals that source the data or or subjects of the data, but they're
12:16 controlled by large internet companies, super aggregators, super data correlators.
12:23 They control the value of the internet. People gain a lot of value of
12:27 interactions, but many of those interactions are designed to maximize
12:32 engagement and often engagement is maximized through rage or other deplorable
12:41 human type interactions. And so we want to have high value interactions on the
12:50 internet that are valuable to the people interacting. They're not being exploited.
12:55 So when you think about building a system, you think about, well, how do I build
12:59 something? What are my tools? What are the toolkits available to me? And so if my
13:04 toolkit, and these are tools from my tool chest in the garage, these are all
13:09 hammers, various types of hammers. and they work really well with nails. If I
13:16 have a set of screws, those hammers aren't very useful. I need a different toolkit. I
13:20 need screwdrivers. So we need to figure out what our toolkit is because actually
13:25 in security systems, we don't have a choice of toolkits. We've got one. So what
13:33 we have to do is we have to figure out how to make it work with that one toolkit and
13:38 we have to be able to build our systems with just one So if our toolkit is
13:44 screwdrivers, we've got to build everything with screws. If our toolkit is
13:47 hammers, we have to build everything with nails. So there's really only one set of
13:50 tools for truly secure data control. We only have one. And so we have to figure
13:55 out how to best use that one. And I would say that the existing internet security
14:02 systems don't do a really good job of the existing toolkit. Now, fair enough to say
14:10 that 20 years ago, ago, the toolkit was even worse than it is now. They had fewer
14:16 tools and they did the best they could with the set of tools they had then. But
14:21 we have better tools now, but it's still of the same type of tools and we could do
14:27 better than they did. And so KERI is about recognizing that the tools have gotten
14:32 enough better that we can do significantly better in our toolkit. And those tools are
14:38 entropy-derived tools. So these are primarily cryptographic one-way functions.
14:43 So these are things like cryptographic strength pseudorandom number generators,
14:47 hashes or digests, the ECC key pair generation algorithms, digital signatures,
14:55 encryption. Now, in a few years, we're going to have to add another set of tools
15:01 because quantum computers are going to provide the ability to tax ECC key pair
15:07 generation. And so we need to have post -quantum key pair generation algorithms,
15:13 which NIST has now approved. So it has to be on a roadmap. But for today, we can
15:21 just focus and KERI was designed five years ago. So we can focus on that, but
15:28 KERI is cryptographically agile. So KERI doesn't have already has a migration path
15:32 to be post-quantum secure. So let's talk a little bit about the economics of data. As
15:39 I said, we want to we want to be able to retake control of our data
15:46 and its value. So when you think about economics, it's about value, right? And
15:54 it's about the creation and capture of value. And creation and capture looks like
16:00 extraction, exchange, and exploitation, both in bad and good ways. And so if we
16:07 want to take control over the value of our data, data, then we need some way to
16:13 secure that control. So the goal is control over the value. And there are two
16:18 types of value. There are its, these are atoms. People are built out of atoms. So
16:24 you can think of people as value of people as also atoms. We have things built out of
16:31 atoms, buildings, cars, things. And to secure those atoms, we have something
16:39 called physical security. And there are lots of physical security systems and
16:43 tools for physical security. And for the most part, it's pretty difficult to attack
16:51 physical security. It usually involves putting
16:58 lives at risk to ultimately gain physical control over atoms that are protected.
17:06 Physical security is largely a solved problem. The other type of value are bits.
17:11 This is information value. And the problem with information is that it's digital and
17:18 can be copied. So you have documents, you have places to store data, but you can
17:25 copy information at will indefinitely without losing any of its fidelity.
17:32 Whereas we don't yet know how to copy atoms. We don't yet know how to clone
17:35 people. It requires new atoms. You can build things that look like old things,
17:42 but they're different things. And the cost of building them is high. Whereas
17:49 information, to make a digital copy of information, the cost is extremely low.
17:57 And so information security is by nature a different type of security because we
18:03 can't have a single copy that we protect physically. We have multiple copies. And
18:09 once those copies leak out, then they're everywhere. So, and then the question is,
18:16 you know, what does that look like? You know, from the standpoint of people, you
18:22 know, how do people control, you know, how do we have information security? So, we
18:32 want control over value. We have the two types of security. And the one thing that
18:38 we have, in our toolkit, and remember I said they're entropy-derived tools, is
18:43 that we can have digital uniqueness. It's a very narrow type of digital uniqueness
18:49 and it's called entropy. And basically we can create numbers that are derived
18:59 randomly such that somebody can't guess the number as long as the number is kept
19:05 secret. So if we don't share the number, they can't guess it. And that is the only
19:10 security that we have. Everything else is one-way functions that try to preserve
19:15 that original entropy, that original level of cryptographic security that says they
19:21 can't guess the number. And so that's not a very rich tool set. So now how do we
19:30 control things? Well, we as people, we are its. We want to control bits. How do we do
19:39 that? Well, the way we do that is that we create cryptographic pseudonymous
19:44 identifiers that are derived from entropy and we build a mechanism that allows us to
19:53 prove that we control those identifiers. We're not talking about all the
19:59 information in the world. We're talking about just identifiers. We can control
20:04 identifiers. And if we can control identifiers, And then if we have a way to
20:11 make attribution to information to an identifier, then we can at least assert
20:16 that the source of the information came from the person or entity that controlled
20:25 the identifier. That still doesn't sound very satisfying, but that is all we have.
20:30 So, we have to build from that. So, let's think about it again. to retake control of
20:37 our data, we will first retake control of our identifiers. Now, this is where the
20:42 internet falls down. If you have a domain name, you're renting it. You don't own it.
20:51 You're renting it from a service provider. There's a limited number of those domain
20:58 names, so they're a scarce resource. And so nobody can own it. They just rent it.
21:04 All right. Now, you can maintain rental control indefinitely, but it's still not
21:12 yours. If you create an account on some social networking site like Facebook and
21:22 you get an account there, you don't own that account. Facebook owns that account.
21:27 You can create a username and a password, but you don't own what's on that account.
21:36 And that username and password, they can at any point in time say, we don't want
21:41 you on our account and they can remove you from the account. And so you don't have
21:45 control over the data and you don't have control over the identifier. So since the
21:52 only thing that we can have information security over are group graphically
21:58 derived identifiers, we must first retake control of our identifiers. So that's what
22:05 KERI does. KERI says, we're going to develop a system where each individual
22:09 controls their identifiers and hence their identity. When we talk about identity,
22:16 we're going to narrowly think of it as identifier plus attributes and anything
22:22 that can be securely attributed to that identifier. That's the identity. So it's a
22:29 very narrow definition, but it's the only definition that actually works. If we
22:33 define it more broadly, then we don't have control over it. And so there's lots of
22:37 differences in identity. So I tend to avoid identity in general. And when I say
22:42 identity, I really mean an identifier system security overlay, or I might call
22:46 it an identity system security overlay, but it's really about the identifiers. So
22:51 identifier uniqueness comes from captured entropy. Anybody can capture entropy of
22:56 sufficient strength that there is no ability to attack it. Even a quantum
23:02 computer can't take that away from you if you do it right. So what we create are
23:10 cryptographic pseudonymous identifiers. Those are the types of identifiers. We
23:14 call those cryptonyms. That's short for cryptographic pseudonym. And the hard
23:21 problem is how do we provide provable perpetual control over that cryptonym?
23:27 That's the hard problem KERI solves. It's not ephemeral, not temporary, but
23:32 perpetual control over a cryptonet. If you don't control your identifier in
23:38 perpetuity, then it's not a very useful identifier.
23:44 Now, I want to go from the identifier to the data. If we have the ability to have
23:52 provable control over identifier, what we would like to do is we like to have
23:57 control over data associated with that identifier. So the first thing we want,
24:03 and I call this the four A's of secure data control or A raise to the fourth
24:07 power data, right? So we need an author of the data, the creator, the source of
24:12 truth, the root of trust for that data. And that imbues the author is the only one
24:17 with the authority to control that data, right? So authorship and authority are if
24:24 you can establish that, then you've created the basis of secure secure
24:29 control. Now you need to be able to authenticate any action that you perform.
24:36 So if you create data, you need to be able to prove to somebody else that the origin
24:40 of that data was from you, the author, right? So you need to be able to do secure
24:46 attribution. You need to be able to provenance the data. When we talk about
24:51 provenancing a painting, right? What's the provenance of a masterpiece? Well, the way
25:00 you provenance it is that you trace the ownership of that painting back to the
25:06 original painter, the original author of the painting, the painter. If you don't
25:13 have a chain of custody of that painting all the way to the present day, then you
25:19 can't securely establish that the painting is not a forgery. It may be a forgery.
25:25 Forgers are really good. You can look at the painting and you go, well, it doesn't
25:30 appear to be a forgery. There's no obvious things that make it a forgery. So that's a
25:36 good sign that it might be authentic. But without the provenance, the chain of
25:41 custody all the way back to the painter, you don't know for sure that it's an
25:47 authentic painting. So we want provable origin. We want provenance. We want secure
25:54 attribution. And then if we've created data that we can prove is sourced from us,
26:03 then we want to be able to control what happens to that data. And that means
26:09 authorized the use of that data, give permissions, consent. It establishes what
26:17 people call a loci of control for the data. That is the domain over which you
26:25 have control. So if the data is in your loci of control and you maintain that loci
26:31 of control, then you have control over the data. And so you need mechanisms to
26:36 authorize the use of that data or what happens with the data or anything else.
26:43 And then finally, a property that is not cryptographic at all is authoritative. For
26:50 data to have value, it must have
26:58 a creator, it must have a provable origin, the use of it must be authorized, but the
27:05 data also has to be authoritative. It has to be credible, accurate, reputable. And
27:10 so we need mechanisms for that which we can bootstrap on top of the other three.
27:15 Let's now go back to the trust basis of humanity when we interact as humans and
27:22 think about how we interact as humans because we're built really well for those
27:27 sorts of interactions. Our brains and our senses and how we function, our culture is
27:34 all has been designed to enable us to function really well with the human trust
27:41 basis. And in the human trust basis, we interact with people in person. We see
27:48 them, we touch them, we hear them with our physical senses. And over time, we get to
27:54 know people from those in-person interactions. And so that knowledge,
28:00 right, that we as a human can know other people means that we can then trust them.
28:06 And how we trust them is based on those physical interactions, right? As humans,
28:13 we're interacting. And so we build the ability to trust other people and to trust
28:21 what they say and what they do, right? And it doesn't mean that we aren't fooled or
28:27 tricked or people don't lie. All of those things happen. But we have a mechanism by
28:32 which we operate fairly well that works pretty well, has worked pretty well
28:37 throughout history. And we have lots of institutions that bulwark that human trust
28:45 basis. The problem is, is on the internet, we can't really know somebody human use in
28:52 the human trust basis because we don't interact with them physically. We don't
28:55 see them with our senses. We don't touch them. So we can't really trust what comes
29:02 over the internet because for all we know, the bits that came over the internet
29:08 didn't come from a real person or didn't come from the person that said they came
29:12 with. They could have come from somebody else or they could have come from an AI or
29:18 for a bot or from a dog for all that matters, right? It is a much more
29:24 difficult problem and we don't have the tooling as humans to do that. We have to
29:29 use different tools. So we have to be able to switch from a human trust basis to the
29:37 only tool that we have for information security, which is a cryptographic trust
29:41 basis. For those of you who don't like cryptography, this is probably not the
29:45 thing you really wanted to hear. But a cryptographic trust base is the only one
29:49 that we have. And to the extent that we can use a cryptographic trust basis, then
29:54 we can have really strong information security. To the extent that we use other
29:59 trust bases, then we're not going to have strong information security. So one of the
30:06 goals of KERI is to provide strong information security without requiring
30:12 everybody to know anything about cryptography. You just need to know the
30:16 best practice for using it and hopefully all the tooling under the hood hides all
30:21 the cryptography from the person. You know, this tutorial is to lead up to for
30:25 people to get to understand KERI at increasing levels of depth. So this is
30:30 really high level theoretical abstract, but we're going to start going deeper as
30:36 we get further along. So one of the problems we have to recognize is that
30:41 cryptography has limitations. For example, one of the cryptographic tools that we use
30:46 heavily is a verifiable digital signature. And it depends on something called a
30:51 cryptographic public-private key pair. It's also called asymmetric crypto. So
30:56 with a digital signature, you can take a statement. This is a digital statement.
31:01 You sign it with a private key and you can verify it with a public key. This makes it
31:05 very useful for communicating over the internet. And it enables the strongest
31:13 form of security because you're not sharing a secret. And what does that mean?
31:18 mean? Well, with a digital signature, any signed statement is non-reputable by the
31:24 controller who signed it. What we mean by controller is the individual entity or
31:29 natural person that controls the private key, right? Because in order to sign it,
31:34 you have to have the private key. So, what does non-reputable mean? It means the
31:39 signer cannot plausibly deny that they created the verifiable signature.
31:44 Therefore, we may only verify the controller of the private key and we call
31:49 this the who that made the statement. So the author, right? But not the veracity of
31:55 the statement. We can't use cryptography to prove the veracity or accuracy or truth
32:01 of a statement. And that's the what, right? But we can prove the who to at
32:08 least the level of plausible deniability. Okay. In order for that to occur, the
32:15 assumption is that the private keys behind a digital signature, the private key or
32:20 keys are truly private, never shared, right? And that the signing, the act of
32:27 signing reflects the signer's true intent. And we call this these two things
32:32 together, the signing infrastructure. And we say the signing infrastructure was not
32:36 compromised. So, for example, if somebody steals your private key, then they can
32:42 sign stuff and impersonate you. They can say they are who you are and somebody
32:50 trying verifying it will say, well, it verifies, therefore it must have been
32:55 signed by the private key. And so if the private key has been stolen, then you lose
33:01 non-repudiation because now anybody, whoever, multiple people now have that
33:05 private key. Correspondingly, if I have a computer or a device that uses the private
33:15 key to create the digital signature, I have to have some way of inputting to that
33:22 device something to be signed. And so that digital artifact that I input to be
33:28 signed, if somebody is able to input something to be signed and I permit that
33:35 signature to happen, maybe it's on my device and they get it onto my device and
33:39 they tricked me into signing it, then now I've signed something that I didn't intend
33:45 to sign. And so that's another type of compromise. So the assumption is that
33:51 either the keys or the signing or the act of signing has not been compromised. If
33:58 that is true, then digital signatures provide non-repudiation to the signer. And
34:05 that gives you a cryptographic basis for securely attributing a statement that has
34:13 an attached signature to the controller of the private key as a source of that
34:17 statement. So with cryptography alone, we cannot trust what was said. It doesn't
34:25 provide that. We have to use it to other mechanisms in concert with cryptography,
34:32 but we can say something about who said it. We can only detect if the signer is
34:38 being inconsistent or duplicitous. So what that says is if you don't know what was
34:44 the statement is true or false, but you do know that the signer made the statement.
34:51 They're basically saying, I say this. So someone could say the sky is green or they
34:57 could say the sky is blue. Well, if they're consistent and they always say the
35:01 sky is green, they may be wrong, they may be misinformed, they may be delusional,
35:08 but they're not being inconsistent, they're not being duplicitous. If on the
35:13 other hand, they say the sky is blue one day and the sky is green another day,
35:18 they're not consistent. Or if they say the sky is green to a set of people and the
35:22 sky is blue to a German set of people, they're being duplicitous. And if they
35:27 sign both those statements and you produce a statement that says the sky is green and
35:32 the statement that says the sky is blue and you see both statements, you verify
35:36 both of them, now you have provable duplicity or provable inconsistency
35:41 depending on how you think about it. And therefore, you have reason not to trust
35:45 the signer. But if you never see inconsistency or duplicity in all of the
35:51 signer sign statements, then you may be able to trust that signer. At least you
35:56 know that they're not being inconsistent. They're not being duplicitous. They still
36:01 may be delusional or they still may be malicious and be a liar, but they're a
36:05 really good liar because they always use the same lie. And that's something. That's
36:12 not nothing. That's really, really valuable on the internet because then we
36:18 can use other mechanisms to hold them accountable for the veracity of their
36:24 statements. And those other mechanisms now are mechanisms that are already
36:30 established. We have all sorts of legal, regulatory, and economic mechanisms and
36:36 incentives that we can apply to incentivize people to have veracity in
36:44 what they say. And those incentives are enforceable if we can prove who said it
36:52 and that a given person or entity said something. And so we start there and then
37:01 we can finish with stuff that isn't cryptographic, but we can't get there over
37:06 the internet without the cryptography because over the internet, it's just data.
37:11 It's not its. So what makes KERI possible? KERI was not possible 20 years ago. It was
37:21 possible probably only 10 years ago. And actually the development of KERI, I
37:27 started working in this space heavily in 2015. It was possible a few years before
37:32 that, but not likely. And KERI was a result of five years of trying to solve
37:38 the secure attribution problem and failing. and then learning from all my
37:43 mistakes. And then in 2019, I wrote the first KERI white paper and 2020, the
37:52 second edition of the KERI white paper, which is largely the KERI we see today.
37:56 And since then, we've been building on that. So what happened in, you know,
38:03 between 20, before 2015 and after 2015? Well, then before 2015, it was generally
38:11 considered by everyone that users could not manage private keys. What I mean by
38:16 cryptographic keys, to manage them, to store them, create them, not lose them,
38:22 use them to sign things. That was too hard. In fact, the DNS certificate
38:27 authority system and the federated identity, OIDC, OAuth, all of those
38:32 systems are based on the idea that the average user can't manage private keys. So
38:41 we get federated identity largely with things called IDPs or identity providers.
38:48 Identity providers are enterprises or institutions or entities that have the
38:56 capability, they have the education, they have the technical know-how to manage
39:00 private keys. And everybody else is a relying party because they're not managing
39:04 private keys. So we built a system based on this assumption, the impossibility of
39:11 user-managed private keys. It doesn't work very well anymore. Now, post-2015, we have
39:16 mobile devices. We have mobile phones that are essentially supercomputers in your
39:23 pocket that have devices and, you know, hardware security modules, multi-factor
39:29 authentication, secure boots, secure enclaves, password management apps. And a
39:35 lot of that was actually a result of all of the excitement over blockchain that
39:41 started in the big inflection point, I would say, is 2015. That all of a sudden
39:48 now, because all of blockchains and cryptocurrencies are based on users
39:52 managing private keys. And so users were forced to figure out how to manage them
39:56 and people were forced to develop tooling to manage private keys. And so that
40:01 generated a whole bunch of effort that resulted in private key management. So
40:07 when it came to solving the identity problem and creating a trust spending
40:12 layer, I could say, well, I can assume that users can manage private keys. So I
40:17 can assume that people can control identifiers that are cryptographically
40:21 derived from private keys and therefore they can use those private keys to do
40:25 secure provenance of those identifiers. So now I have the ability to do that. So 2015
40:31 practical user managed private keys. And since 2015 15, it's gotten even more
40:36 practical. I mean, the user experiences has gotten much, much better. People now
40:41 regularly use passkeys, which under the hood are just public-private key pairs.
40:45 This is something that we shouldn't say anymore, that we can't build identity
40:51 systems where the basis of the identity system is on an outdated assumption, the
40:59 assumption that users can't manage private keys. That's outdated. We can build them
41:03 in And we have devices that do that. So then we had to settle for good enough
41:10 security from federated identity. And federated identity has lots of security
41:14 problems. Primarily because it's based on shared secrets. And shared secrets are
41:20 reputable. And now those shared secrets are phishable or spirit phishable or any
41:27 number of attacks. And so, you know, a shared secret is a password. A shared
41:33 secret is a OAuth bearer token. Shared secret is a TLS exchanged cryptographic
41:41 key that is used to do a TLS handshake to provide what is called authcrypt. It's a
41:47 weak authentication mechanism that's reputable and we shouldn't use anymore.
41:51 But the whole internet is based on it. So that meant that with good enough security,
41:56 you have to have secure sessions. You ended up with perimeter security with VPNs
42:01 that also use shared secrets because you Every user of the VPN is using the same
42:07 private key because the IT admin is sending out the same client certificate to
42:12 all of the users. Now we can have identity based on user managed private keys. And
42:19 that means we can have a difference in security that is different in class
42:23 because we don't have to ever use shared secrets ever again. And KERI is that. KERI
42:30 is a protocol designed to maximize that. So let's talk about private key
42:35 management. What that means is that you have controlling keys. You have key pairs
42:42 for a digital signature. The controlling keys are the private keys. You create an
42:47 identifier. We haven't said how we create the identifier. We'll get into that. But
42:51 abstractly, you create an identifier from those controlling keys. You now have data
42:57 and you use that identifier and some cryptography, namely digital signatures,
43:03 to establish secure authorship or attribution over that data. The problem is
43:11 that the continued use of private keys expose them to what are called side
43:15 channel attacks. What that means is that they're not actually attacking side
43:21 channel means they're not directly attacking the digital signature. The
43:24 digital signing algorithm, if you're using elliptic cryptography, especially the most
43:30 secure ones like ED25519, It has been secure for the last 20 years. And multiple
43:38 Moore's laws increases in computing power have not materially weakened the security
43:43 of those digital signatures. So elliptic curve digital signatures are secure. Now,
43:48 when quantum computers come around, that won't be true anymore, but we already have
43:53 new cryptographic algorithms that replace ECC that give us the same thing as just
43:58 the key sizes are bigger and take more computation. But it's still not vulnerable
44:03 to direct attack. A side channel attack means you're not breaking the crypto,
44:09 you're breaking the key management infrastructure and you're breaking the
44:13 signing infrastructure. And so the more you use private keys, the more you use
44:19 your signing infrastructure, the more likely an attacker is to figure out how to
44:23 break your use of it, not the cryptographic algorithm, but the way you
44:28 use it and the systems you use it on. And so what has happened is what happens then
44:34 is that practically speaking, the keys become weak from exposure. The more you
44:41 expose them, the higher the likelihood that one of these side channel attacks
44:45 will be successful. So the way to manage that, so this is the hard problem with key
44:51 management, is that your private keys need to be revoked and replaced with new
44:56 private keys. The short term we use that for that is to rotate your keys. You
45:01 rotate from an old set of keys to a new set of keys. And the new set of keys give
45:07 you a fresh start that haven't been exposed to CIDESHILL attack. And so now
45:11 the attacker has to start over, right? He has to do whatever to try to compromise
45:15 your system. And so if you rotate them often enough, you can stay ahead of the
45:21 attacker in general. Not always, but that's the general practical thing. The
45:28 problem is most systems that are based on public key, if PKI stands for public key
45:35 infrastructure for the PKI system is based on public keys, you must reestablish the
45:41 root of trust with each rotation because the root of trust is based on the public
45:47 key, not an identifier that persists, but the public key. So you throw away the
45:53 public key when you rotate it. Now you have to create a new public key and you
45:57 have to redo all of the work you have to do to reestablish the root of trust of
46:01 that public key as being authoritative for a given person or entity. That means the
46:08 identifier is how you link that person to whatever it is that you want to security
46:17 attribute. And if you throw the identifier away, which is the public key, then you
46:21 have to reestablish all of the reputation. All of that has to be reestablished. When
46:26 you have a compromise, you break the chain of trust of control over the identifier.
46:32 So if the private key is compromised, then the public key, the provenance is gone,
46:36 everything's gone. So you go, well, wow, that's really hard, right? I have to do
46:41 private key management if I want, if I, you know, to be able to do cryptography.
46:47 But now the hard problem is not the cryptography. The hard problem is the
46:51 management of your private keys, right? So key compromised recovery is how you fix
46:59 this problem. You need a mechanism that despite your key management breaking down,
47:06 can you regain control? Can you recover from that? So the hard problem of private
47:13 key management is key rotation with key compromise recovery, right? So that even
47:21 if your private keys are compromised or your signing infrastructure is
47:25 compromised, that you can recover control over an identifier that persists despite
47:30 key rotation. KERI solves this hard problem. Until KERI came along, nobody
47:35 solved this problem. The other people have now copied KERI and some parts of KERI.
47:40 But in terms of a full system that solves this hard problem, as far as I know, KERI
47:46 is still the only protocol on the planet that is public and open source and open
47:52 standard. There may be proprietary ones that I don't know about, but of all the
47:56 public ones, it's the only one that I know about. That's the end of this discussion.
47:59 So hopefully I've whet your appetite for understanding what KERI does because I
48:05 basically told you how KERI solves the hard problem with key management. And if
48:10 we don't solve the hard problem with key management, then we can't control our
48:14 identifiers on the internet, which means we can't control our data and we can't
48:18 control value of our data. So if we really want to control the value of our data on
48:24 the internet, we need to control our identifiers and we need to do key
48:27 management to do that and to do that we need KERI. So I hope that's sufficient
48:33 motivation. Thank you and remember to go back up to the first slide has links where
48:40 you can go do some more research and look for additional tutorials on this topic.