Trust assertions
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 64 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45894 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 201155 / 64
3
7
10
11
17
19
21
28
33
34
35
37
40
44
48
49
52
55
57
59
62
63
64
00:00
Information securityReal numberSolid geometryDifferent (Kate Ryan album)CryptographySoftware maintenanceSoftware developerCartesian coordinate systemLecture/Conference
00:42
Arithmetic progressionBitKey (cryptography)Open sourceDifferent (Kate Ryan album)Multiplication signProjective planeEvoluteCryptographyCartesian coordinate systemOpen setReal numberPublic key certificateGoodness of fitTouch typing
01:59
Public key certificateKey (cryptography)Data storage deviceCartesian coordinate systemDecision theoryAuthorizationOrder (biology)WordUser interfaceInformation securityConsistencyComputer animation
02:56
Thermal conductivityDecision theoryCartesian coordinate systemInformationPublic key certificateDifferent (Kate Ryan album)Form (programming)Backdoor (computing)WebsiteBitContent (media)Computer animation
04:05
Public key certificatePublic-key cryptographyAuthorizationFingerprintException handlingPersonal identification numberLevel (video gaming)AuthenticationDifferent (Kate Ryan album)InformationComputer animationWebsiteServer (computing)Web browserDecision tree learningCartesian coordinate systemDecision theoryCuboidCASE <Informatik>Computer animationXML
06:17
Decision theoryContent (media)InformationLevel (video gaming)Different (Kate Ryan album)Multiplication signBuildingComputer filePosition operatorSource code
07:03
Process (computing)BuildingNegative numberPosition operatorInformationComputer iconPublic key certificateNumberDecision theoryCASE <Informatik>ChainRoutingDecision tree learningComputer animation
09:05
Decision theoryData storage deviceKey (cryptography)Social classDifferent (Kate Ryan album)Public key certificatePublic-key cryptographyShared memoryTheoryBitCartesian coordinate systemWordOnline helpType theorySimilarity (geometry)CryptographyObject (grammar)Information privacyAttribute grammarComputer animation
10:38
Public key certificateHash functionPublic-key cryptographyReliefAttribute grammarEntire functionQuicksortNumberString (computer science)Electronic mailing listType theoryException handlingMiniDiscCodierung <Programmierung>CASE <Informatik>Process (computing)Social classPersonal identification numberRepresentation (politics)Different (Kate Ryan album)CodeField (computer science)Theory of relativityComputer animation
12:59
AngleBitDecision theoryCartesian coordinate systemTransport Layer SecurityGraphical user interfaceMereologyConsistencyPublic key certificateObject (grammar)AuthorizationImplementationLatent heatException handlingPublic-key cryptographyLengthCryptographyPhysical systemData storage deviceKey (cryptography)Computer animation
14:31
Module (mathematics)Graph (mathematics)Lie groupCountingCoordinate systemInformationSystem callLink (knot theory)Multiplication signBitDecimalArithmetic progressionDifferent (Kate Ryan album)Order (biology)1 (number)Physical systemMehrplatzsystemRevision controlPublic-key cryptographyComputer configurationConfiguration spaceAdditionContent (media)Basis <Mathematik>Software development kitOperator (mathematics)DivisorDirectory serviceFunctional (mathematics)Computer filePoint (geometry)Projective planeBoom (sailing)Personal computerStructural loadPrototypeProxy serverLevel (video gaming)Error messageProcess (computing)Uniform resource locatorSingle-precision floating-point formatCryptographyComputer animation
19:10
PermutationCommunications protocolRight angleEnterprise architectureCartesian coordinate systemModule (mathematics)Field (computer science)Set (mathematics)Proxy serverEmailDirect numerical simulationPublic key certificateUniform resource locatorAddress spaceComputer fileConfiguration spacePoint (geometry)String (computer science)Video gameBitData storage deviceLatent heatLink (knot theory)AlgorithmPlastikkarteCycle (graph theory)Electronic mailing listSoftware development kitData managementStructural loadLoginLimit (category theory)Physical systemPersonal identification numberReal numberEndliche ModelltheorieObject (grammar)MultiplicationMereologyQuicksortMaxima and minimaComputer hardwareMultiplication signDifferent (Kate Ryan album)Goodness of fitLevel (video gaming)Exception handlingType theoryAdditionGroup actionService (economics)Coordinate systemToken ringBoom (sailing)DatabaseUser interfaceLastteilungCache (computing)Negative numberDirectory serviceUsabilitySingle-precision floating-point formatDimensional analysisInternet service providerContext awarenessCASE <Informatik>Bounded variationObject modelPublic-key cryptographyRoboticsComputer animationComputer programmingFlow separationEvent horizonBeat (acoustics)Digital photography1 (number)Polar coordinate systemNumberSimilarity (geometry)Cohen's kappaArithmetic meanSocial classPole (complex analysis)Attribute grammarReading (process)Intrusion detection systemCustomer relationship managementTransportation theory (mathematics)Commodore VIC-20Speech synthesisHeat transferLecture/Conference
Transcript: English(auto-generated)
00:00
I'm Steph Walter, and I am really interested in desktop crypto, making crypto usable on the desktop security that's integrated between all the applications, where developers have a real solid foundation to build on. I'm excited by different advances in crypto, different, sometimes crazy, sometimes fascinating ideas.
00:27
And I think all of that comes out of a real solid base for understanding and using the crypto that we already have. I work for Collabra, and I'm the maintainer of known keyring and a C-ORCE developer.
00:41
So, what brings me here is that we've been using PKCS11 as a glue to bring together different crypto libraries. Projects like OpenSC, NSS, GlueTLS, all really excellent, good, good stuff.
01:01
I mean, with different focuses and stuff, and that kind of diversity is what we need in the Linux desktop. That is the real key of open source, is that evolution through diversity. And so, on the other hand, users are kind of torn between having to choose.
01:21
Some applications use a crypto library one way, others use it another way. And so, what we need is a way to access the same certificates, keys and stuff, across all the different crypto libraries. Now, Nikos talked a little bit about that, and together we've been doing some interesting research on the different problems that you face when you try to do that.
01:44
So, today I'm going to talk about one of those problems and a solution that we found for it. And hopefully, if we have time, touch on a few more that are in progress, kind of tagging on to what Nikos discussed earlier. Sorry. Okay, I'm talking about trust.
02:05
Not only do we have to store keys and certificates and present them to all these applications and libraries in order to have a consistent user experience, but we have to have applications make consistent trust decisions.
02:23
Like, for example, the most obvious one is whether to trust a certificate authority or not. Now, trust is a very ambiguous word. And if you say trust in a room full of people, everyone's going to think something completely different. It's the kind of word we shouldn't be using, especially not in user interfaces.
02:44
In security we want unambiguous words, we want precise definitions. Trust is precisely imprecise. So, we shouldn't abuse that word, but I'm going to abuse it today a whole lot. I'm going to abuse it enough to make Jean-Luc Picard do this.
03:02
But we have a specific concept that I want to talk about today. It's called trust assertions. And rather than being an imprecise concept, trust assertions represent something very...
03:20
It's a standard concept that we've all seen in different forms, but it's boiled down into this phrase, this tag. Trust assertions expose little bits of information that are necessary to make a trust decision. Trust assertion represents the trust of the user or the application that's running in a subject,
03:47
like a certificate, for a given purpose, connecting to a website. Trust assertions don't represent the decisions themselves. They represent information that applications and libraries can then use to make a decision.
04:06
A trust assertion is essentially a tuple, or a triple, containing these three things. A subject, a level of trust, and a purpose. A subject might be a fingerprint, it might be a certificate, it might be a public key.
04:23
A level of trust, trusted, distrusted, or might have an introducer level of trust, or introduce another subject, and a purpose. Trust without a purpose is something that you don't see very often in the real world.
04:40
You trust your bank with your money, your school with your kids, but not necessarily vice versa. There's very little carte blanche trust in the world. Most people don't even trust themselves with anything. So here's an example of a trust assertion that you might have seen. A certificate authority is a trust assertion. It's a fact.
05:04
It's a piece of information that's stored, that represents that piece of information can then be used by an application to make a decision. So here we have the certificate as the subject, introducer level of trust, and server authentication, also in the case of this first checkbox, is the purpose.
05:26
And this is the Firefox screenshot. These three different checkboxes represent, really, three different trust assertions. When you check that box and install this CA in your browser, you are creating trust assertions.
05:43
Here's another example. This is a certificate exception. When you access a site that the CA is not installed, it's routed in one way or another, prompts you to either leave the site and run away or to add a certificate exception. We call it a PIN certificate.
06:03
So here we have a different level of trust, just trusted. It's not an introducer anymore. And the purpose is further refined. The purpose is to connect to a single website. Notice that these are positive trust assertions. They tell you information that builds trust, that adds to a trust decision
06:29
in a way that eventually, if all the criteria were met, that subject would be trusted. Here's another one. This one's a little different. We've all seen it, SSH. When the first time you connect to a host, you have the subject of the trust assertion
06:44
as the public key, trusted level, and the host as the purpose. Yes, it actually adds a trust assertion to your known host file. These are all stored in different ways in different places, but they're essentially the same concept.
07:00
Again, this is a positive trust assertion. We're building trust. Here's a negative trust assertion. I couldn't get a screenshot of a CRL, so I got this ugly icon. Basically, a CRL consists of a bunch of trust assertions. We are stating that this subject, represented by a serial number and an issuer,
07:24
is distrusted for any purpose. Turns out that with distrust, the purpose being cart-launched makes much more sense. You cannot trust someone to do anything. You can distrust someone for any purpose whatsoever.
07:46
Here's one more foundation concept before we get into the actual details of how this helps us. Building and falsifying trust is a process that you go through with trust assertions. Initially, you start off with an unknown trusted subject, something that you don't know the trust of.
08:10
You use positive trust assertions to build up trust. You look for, do I have any information to make a positive trust decision about this?
08:21
Once you have that, in this case, this example, we build a certificate chain. Oh, look, there's the anchor. We found that as a trust assertion. We load some certificates. They introduce each other. We have that. Then we use negative trust assertions to check if we should falsify that trust. The important concept is that positive trust assertions operate on untrusted subjects.
08:46
We don't know yet the trust of them. We build up the trust with positive assertions. Negative trust assertions operate on something that would otherwise be trusted. This is in the case of the CRL. Maybe we found one of these certificates are revoked.
09:03
We falsify the trust of the whole chain. How does this help us to share trust decisions? Help the user see a consistent or predictable principle of least surprise trust decisions from all these different applications and crypto libraries.
09:24
Well, what we've done is we've stored trust assertions in PKCS11. Just like certificates are stored in PKCS11 and keys are stored in PKCS11. Now, we store trust assertions as one object per trust assertion.
09:44
They don't necessarily have to be stored on the same token as the subject that they are representing or referencing. They can be stored somewhere else. They don't have to be stored with the certificate that they are representing. Each one has a class and different types.
10:04
Kind of like public keys in PKCS11 where you have a public key class or private keys. Then you have different types of public keys. Similar concept. The theory of trust assertions is kind of obvious and simple. But as so often happens when theory meets reality, things get a little messy.
10:24
So we might turn things around a little bit when I show you the attributes that we use in PKCS11. Because it just makes it simpler to access, simpler to look up, more consistent. So here we have an example of a trust assertion stored in PKCS11.
10:44
These are the different attributes that we use. We have a class of CKO X trust assertion. And here is the type. Now in this case we are representing an anchored certificate. So here is the type that represents it.
11:02
We have a purpose. The purpose is a string. We were thinking it could be an OID perhaps or something like that. You know the during coding of an OID as is used elsewhere in PKCS11. But a string really gives us the flexibility that is needed. For new uses of trust assertions.
11:21
So that for example, trust assertions unrelated to certificates could also be stored in this proposal. Then the subject is the certificate value. The entire certificate der encoding. Some other concepts that are similar to this might use hashes.
11:43
But we live in a world of completely unstable in relation to hashes. You know they are going out of style like clothes these days. So we have chosen to use the entire certificate value as the subject.
12:01
And here is another one, a pin certificate. Notice there is an extra field here. Which is the peer that certificate is pinned to. Essentially this is a certificate exception. This is what you would look up. If you wanted to check if there was a special exception for it. A given host connect to that.
12:24
And we have the distrusted certificate trust assertion. Now this one is a little different. A subject, we use the issuer and the serial number together to comprise the subject of the trust assertion.
12:43
So that we can represent things like certificate revocation list. Which certainly don't contain the entire certificate. We wouldn't know what that certificate actually, the der encoding of it is. Or even hash or anything like that. This is a negative trust assertion.
13:00
These are the implementations of trust assertions in PKCS11. It is being implemented in GLib. They have new TLS support. And the implementation that is going to be merged is It uses PKCS11 trust assertions to look up information like about the CAs. On the system about storage exceptions.
13:22
And about CRLs and things like that. Now Keering has support for storing these. And libgcr is a GUI library that has support for looking about for using them. And we are looking forward to new TLS supporting them in some way. And we also have a compatibility layer that exposes trust assertions as NSS trust objects.
13:43
So that NSS can use them too. In the specification, there is a bunch of answers as to why we do things a certain way. The decisions that are made. And it talks a little bit about NSS trust objects as well. So that is part of the glue that we are using to connect applications.
14:04
When it turns out on the desktop, people are really interested in making certificates and keys work. But they are even more interested in the problem of having to install the certificate authority in a hundred places. And basic things like that don't yet even exist. So that is why we are coming from this angle solving those problems.
14:22
As we get a better foundation for consistent crypto experience. Then things can develop even further. And we have more glue. The P11 hit that Nikos mentioned. I have been working on that. But this is really a work in progress.
14:41
So I haven't had time to flush it out. At least classify it. And we love as much participation as we can get. Because this is the kind of thing that everyone... We need, in order to solve this problem properly, we need lots of people to get behind it. Now, the first problem was the initialization problem that Nikos talked about.
15:04
Multiple users of the PKCS11 module in the same process have this problem where they both try to initialize it. On initialization, the second guy gets an error. CKR already initialized. And... Which is not an error. Which is not actually an error. But let's say you ignore it.
15:20
You say, hey, okay, fine. I know that guy. Ignore him. Then when you come around to finalize, then what do you do? Who finalizes? One guy comes in and finalizes and tears it out from the other guy. And nobody finalizes and resources aren't free. Stuff's locked. It's just... It gets kind of messy. So what we've done is come up with a concept that...
15:40
You could have a single PKCS11 library that loads a bunch of different other ones. And coordinates access to them. Ref counts, initialization, and finalization of them all. So you basically... It exposes all the slots from those guys as slots in one library. In one module.
16:02
And by doing that, you can call initialize as many times as possible. It never actually returns CKR already initialized. We thinned the spec a little bit. And it counts how many times it initialized. And then you can finalize it the same number of times. And it fixes that problem. In addition, once you have all those different users
16:24
on a desktop or in a distro, using that method to access the various installed PKCS11 modules, it brings you into a single place where you can also do configuration. Which ones are installed? Well, obviously, this module will need to know which ones are installed.
16:42
We'll need to decide on a configuration standard, whether it's files in a directory or a config system like Nikos was talking about. And we can also expose library functions. So you can use this as a module. For example, NSS can load this module. This proxy module.
17:02
And boom, all the installed PKCS11 modules on the system, they're there. Or you can be aware of P11. Let's say you want to link to it directly. You can link to it as a library. And then you have access to all those modules,
17:22
the information. You can initialize stuff. And it will ref count stuff for you. And you can access the config. Let's say you have special config options. We work out some kind of config system. You can access the config in different ways. I've been talking with Joe Orton of perhaps bringing in some functionality from Pak Choy.
17:45
Is that how you say it? I don't know. And perhaps PKCS11 URL support if we want that. But essentially, the problem is that if we're going to use PKCS11 on the desktop, and we're going to have the diversity of crypto libraries that we currently do,
18:03
then we need a coordinating factor in there. This P11 kit could also, if a library was marked as fragile or something, could coordinate access to it so that only one could perform an operation at a time or something like that.
18:25
It could do things like that if we wanted to. Of course, we want to keep this simple. We want to keep it to the point of what we're trying to do. So P11 kit is currently kind of in a prototype stage. BSD11, I'm sorry, BSD licensed. You say PKCS11 too much and you start fitting it in everywhere.
18:44
And it has no dependencies. I mean, I guess it has pthread dependencies because, as you know, PKCS11 essentially needs some kind of threading going on there. But hopefully, we can have this project take off and solve this problem. Without it, we're kind of up a creek as far as using PKCS11 robustly on the desktop.
19:09
So, that's all I had. Any questions? Yes, I have two questions. The first one is, why did you prefer to invent new trust objects instead of using the same model that NSS uses for trust objects?
19:25
Yes, it's detailed in the spec towards the end. I actually went through and documented the NSS trust object model because it hadn't been documented and added to the documentation. And I was really hoping we could use that.
19:40
But there are several reasons that we didn't. One is that it stores multiple trust assertions on the same object which really gets complicated as far as looking up and especially storing them. It's not extensible. You can't add more different purposes than NSS and Firefox use. And most importantly, it doesn't support things like certificate exceptions where in addition to the purpose,
20:05
it consists of a type of use and a host or an email address or those things. So, those things just don't exist. And once you run into those problems, you realize that it makes sense to start afresh. I think that trust objects was a good idea but it's like 10 or 15 years old.
20:21
And now here, we're in kind of a different climate and different stage. But, GNOME Keyring exposes all the trust assertions it contains as trust objects, as NSS trust objects as well. So, you plug that in, boom. Your CAs from GNOME Keyring automatically work there. So, you can do stuff like that. Okay, thanks.
20:40
And the second one is actually more a comment. You might have heard that Fedora has also introduced some new system-wide PQCS11 token or the global shared database. So, you can have a global list of your system-wide trusted CAs.
21:01
So, do you think there is need for coordination between your coordination attempt and the things that Fedora and NSS are trying to do? Yes, we should definitely coordinate. What we're trying to do here is provide it to everyone. And sometimes, with NSS, I like to coordinate with them but it's hard
21:21
to, in many cases, get them to understand that there are other crypto libraries. I already... I like that communication. Okay. We're going to have more of it. I already... We have that mailing list, the news group actually. Are you aware of that? Tech Crypto. Yes. I'm on that mailing list.
21:41
Okay, wonderful. And I posted some stuff earlier about trust objects and things. Do you have feedback? Not much. I don't remember. Not much. Okay, well, thanks a lot. That's great. There are many things you provide as a library that could make sense also as a service. We talked about, you know, peering.
22:02
But there are different needs about relocation. The fact that you need to update CRLs. Things that are maybe implemented in the NSS. You have refreshing OCSP checking kind of stuff. And one of the things that will be useful for desktop that can't be used when you use your proxy or P11 kit is having to enter the pin caching.
22:32
It's kind of a tricky question because you might want sometimes to actually have a user... The talk is not yet over. Could you please wait outside a little bit longer?
22:41
We will open the door when it's finished. So please close the door so we can listen better. Thank you. Pin caching is an issue that is good for the desktop. And sometimes you want it and it would be good that something would be done as a service. And sometimes you don't want it. You don't actually want the user to use it.
23:00
I have actually a question. Why all the applications want to cache the pin? You said it should be done in the first place. By all the users? Yes, in many cases. I mean, it depends. I think that smart cards that shouldn't cache the pin should provide an outside way to do it. Of course that's more expensive.
23:22
I didn't say the application had to do it. I said that in some uses you don't want the user to re-authenticate over time. As far as CRLs, I'm working on a module that exposes directory CRLs as trust assertions. So they can just be looked up however they want.
23:44
And anything can update in a daemon or whatever. Now, of course, there's many issues to work out there. And that's why I'd like to collaborate with NSS. You know, that's the kind of thing that would be perfect to collaborate on. And so I hope that... And how about ACS on trust?
24:01
Because if anyone can remove trust assertions, negative trust assertions... How can we trust the trust assertions? Well, yes, that's always a problem. Especially if you're speeding up CRLs into a single trust assertion that can't be verified anymore.
24:20
It becomes a little bit difficult. That's a good point. And NSS makes it so that you can expose the entire CRL as another object. So if you want to access the whole CRL and get involved in that, you can. So right now in the logistic searches and in the search, we sign typically the DM.
24:43
And then we sort of like extract the FQDN or something like that from them. And increasingly we sort of like have court members sitting alongside the FQDN. Or in case of email addresses we get similar variations. A lot should be there at least 500. We take that variance into account.
25:00
So we sort of start paper on a pure FQDN and things like that. And as we sort of get into two IP worlds now, that starts to increase and you become a problem. Is there a point, do you think that what you're doing right now in trust data risk is robust enough? Or is there a point where we need an extra dimension where you say like, actually I'm only interested in this context which is either a port or a protocol
25:20
or even more narrow permutation shootable for enterprise use where you don't like load balancing and things like that. Where one IP has to be met. Are you talking about the CKX peer attribute? For example, it's throughout the whole stem. I'd like to flesh that out. I think it's, yes I agree that it's kind of naive right now.
25:43
It might be good to use something like subject alt name string. Like the way that they're represented in most user interfaces with that. Something in a colon, DNS colon and then the host name. Or email colon and then an email address or something like that. And then you could work like that. The concept here is to make something that is robust and flexible enough to use.
26:04
Not just for certificates but also other uses. And so maybe something like that would fit the bill. That's why I want to shy away from using, enforcing OIDs. I'd like to make it available in the purpose field. It's the same kind of thing. Maybe an application wants to store trust assertions that only it can then, specific to itself.
26:25
Then perhaps it wants to just put a string in there or something. So that's the kind of stuff we need to fine tune. It's a good point. Do you plan to manage a little bit of the life cycle of the smart card? Like initialization and transfer? Or leave it for NSS?
26:42
In which part? In, okay. In GNOME QA. Generally we just support consuming the stuff on the smart card. But Seahorse is a key manager that's growing PKCS11 support.
27:01
So you'd probably be able to do basic things on it. Like export a certificate or maybe put something on there. We're not sure how far we'll go. Once you get into initialization it starts to get very specific to the smart card as well. There are two comments to remember. One is from Robert on the Netscape list that they basically gave up on personalization.
27:29
And the other comment is from Pegasus about a specification that says that initialization is usually left to outside of the scope of NSFEC. So there are kind of, you can do some stuff.
27:42
But in real life it's kind of limited. So both need to work on it. That's true. And one last thing I wanted to say is that we're using PKCS11 for this stuff. Now we're using it because it's there and it's implemented in all these different places.
28:03
It's not necessarily perfect. We're using it pragmatically because it already has such a big user base. We're storing trust assertions in PKCS11 not because that's the perfect way to do it. In theory. But because it works. You can do things like using the login system, the pin system of PKCS11 and all sorts of other bits and parts of it to make it work.
28:28
So here's a thought on that note. I asked Nikos or I commented during Nikos talk that maybe an API, a configuration API is really the minimum sort of
28:45
puzzle, piece of a puzzle that is needed to not have to enter the path of a PKCS11 provider URL in my settings. Because that's what I want to get away with. And using PKCS11 as a conduit, be it not perfect but maybe with good buy-in, doesn't really solve that.
29:11
Well what solves it is... You have the API. Right? P11 kit, if it's going to become the place for desktop applications or applications that have multiple PKCS11 users to kind
29:24
of come together, coordinate and ref count their usage, we are adding, and it's already there, a configuration API into that place. If we're going to use a single library, it's a small little library to coordinate this stuff, you might as well add the configuration thing that just works.
29:41
Of course an application is free to ignore it, but it's there and it's usable. And it's already kind of prototyped a bit. We have one file module so that applications, or rather like OpenSC, can install a file in a known location and then it becomes available to other stuff.
30:02
There's global settings that could be there and then there's per module settings that can be used in different ways. The proxy module that I talked about that loads all those PKCS11 modules and exposes them as one module that's ref counted, that uses the config API internally to actually load those things. But we also expose that so if your application is aware of P11 kit and actually links
30:24
to it, then it can use those config things, it can load up stuff like, perhaps there might be settings, we might define settings that say, on this token, these algorithms are hardware accelerated. So if an application wants that, it can go and check those things out. So those are the kind of things that we'd like to see come together.
30:44
Time's up. Really, very, very great stuff. Thanks.