 Okay, is the mic yes, it's working so What I mean by rich authorization is authorizations that go way beyond simple things like like passwords and H max or even asymmetric key digital signatures What I mean by a resource constrained device is specifically very small amounts of memory Talking about hundreds of bytes not kilobytes and certainly not megabytes The implementation of this Some of you people know about TPM policies and TPM 2.0. That's an implementation of it If you're interested in that great, even if you're not interested in TPM 2.0 I hope that this will trigger some thinking about What you can do as far as authorizations using very small amounts of memory a Typical example of what you would authorize is a key like a public key or a symmetric use of a symmetric key But it goes way beyond that as well into clocks memory and Nonvolatile memory administrative commands, and I'll try to give a lot of examples of it I'm going to start with a few slides on the The mechanism how how it works underneath, but then I want to go pretty quickly into use cases So this is an example of an immediate Assertion where the entity over on the left Has a single policy digest represented by policy see In order to Satisfy the policy you start a session the session has again a single session digest It starts at zero and then you send in a bunch of policy commands and here I show three commands if the commands Verify correctly Then the session digest gets extended in the in the TPM sense where You take the old digest you append some data to it you hash that and you get a new digest So these digests accumulate as the commands come in and it goes from a to b to see Once you get to see You're ready to actually run The command that you've authorized at that time. It's a simple mem compare of the Digest that's in the policy of the entity to the digest that's in the session and in this case they match they're both see and The the authorization succeeds These are called immediate assertions because the validation is done When the policy command is sent in so there are these three commands And they're checked at the time the command is sent in not at the time You're running the actual not at the time that you're using the the key or the entity There's another concept called deferred authorizations here where you send in a policy command and it just updates the session state Something could be checked at this time, but typically it's deferred and Then at runtime when you send in the command and the command parameters It's checked against the session state And so the validation is done at the time that you're using the entity and I will give examples of all of these So if I go back one slide if you think about the way a hash works This becomes an An and Function where you need all three of these commands to succeed if one of them fails Then there's no way to get from a digest of zero to a digest of C So it becomes an and and you can accumulate in this case I show three but an unlimited number of commands and the There is still one single digest in the session. So memory doesn't grow no matter how many Policy commands you send in and then the obvious question would be well, can I do an or and The answer of course is yes the way that an or works is The entity has a policy digest which which is a hash of all the and policies So if you look over on the left there's an and policy C Which was the one from the previous slide and then there's other and policies D E and F They get hashed together to policy N The way that this is Satisfied is you start a session you have a session digest starts at zero as before it progresses from A to B to C And at that time you send in this policy this special command called policy or with a list of Digests and the list here is C D E and F The device will look for a match against one of them if one of them matches then we know everything is okay We replace the session digest C with its session digest and the hash of the list they match and Everything is good. You're good to go. You're authorized So a summary There is there are immediate Assertions which are done at the time that you send in the policy command Deferred assertions are done at the time that you're actually trying to use the authorization there are and terms and there are or terms and I should say that you're not limited to a Bunch of ands and then a single or you can do a Series of or terms you can do a series of or terms and then more and terms to any complexity that you like and The key is that through all of this. There's just one digest Just as a as a level set the most complicated policies that I've seen have typically about three or four and terms and three or terms I haven't seen anything more complex than that, but there's nothing in the design that limits this at all Let's see okay each entity has one has a policy that is one fixed-size digest Something else that's very nice is that if we add more Authentication types in the future if we add more policy commands The structure of the key doesn't change and the structure of the session doesn't change So everything is backward compatible compatible. You can add more features without changing any of the existing structures The session just has one fixed-size state plus any deferred authorizations Something else that might not be obvious is that the policy calculation the policy contains no secrets It might have public keys, but it doesn't have private keys. It doesn't have passwords or anything like that What this means is that you can pre calculate the policies offline and you might have an end even in an entity you might have Each platform has its own signing key each of the signing keys will be unique But if the business logic is the same they'll have they'll all have the same Policy hash the the value of the policy will be the same Okay, some use cases the most Easy to understand perhaps is policy command code. This is an authorization That's linked to a particular command. It's deferred in that The policy command just says in the future you need to check that a certain command code is running Some use cases of this so in the TCG world There's this thing called a quote which is assigned at the station But you can think of other Signings or other commands so you can take a key and you can say I'm going to restrict this key to only Certain types of signing only a quote you can take a symmetric key and you you can say the policy for this command I Can only use it to encrypt I can't use it to decrypt Another very common use is for memory if you want to have Certain policies for writing which might be more restrictive and other policies for reading which are more liberal You would use this policy command code and you would have one or term for rights and another or term for reads delegation so you might have some very highly privileged Administrative Tasks and you can say okay We will have an or term here for example for a firmware update and you'll say well Okay, here's the policy for a firmware update and it might be more or less relaxed or certainly different Than another administrative command like like rebooting or something like that. So that's what you would use command code for Authorization value and password are also fairly straightforward This is saying in order to authorize this You need a password or or an H Mac of the parameters a very common thing would be to combine that with policy command code which would say Say to do our memory right. You need a password to do a memory read You don't need a password. So you would have those two or terms. That's a very common use case Okay, now a more a more complicated one and I'm gonna put my glasses on for this one Nope. Yes, I am So this is this is an authorization tied to a digital signature It has Parameters such as a nonce which would say I'm gonna sign this authorization, but it can only be used once You can lock it to the command parameters. So you could say I'm only going to I can I'm authorizing this but only for certain parameters Policy reference I'll get to a second in a second and an expiration. So you can say okay. I'm I'm signing I'm authorizing you to use this key But only for the next half an hour or only for the weekend when I come back on Monday, you lose your authorization Use cases Authorization using a smart card so you can have a smart card or other HSM Signing an authorization to do something you might have say your Your device here is being used as a CA to sign some software But you don't want to allow anyone to use that CA so you can authorize the CA itself with a smart card something like that Biometric if your biometric can do digital signatures You can authorize say with a fingerprint reader and this is where the policy reference comes along because you don't want to say Anybody's fingerprint who matches works works. You might want to say only Alice's fingerprint Or only Bob's fingerprint. So that's this policy reference and of course because you can have or terms you can say well Alice's authorized with just her fingerprint Bob needs a fingerprint and A password something like that Authorization from a help desk or customer support so Supposing a help desk wants to do something on your system So they can or give you privilege to do something on this on your system They can give you a digital signature over at their IT support department to permit you to do something Delegating your key during your absence so you might be able to use your key with password But you might give assigned authorization to someone to someone else to use it with their password Just while you're at lunch firmware update is a typical example of How you would sign certain command parameters? So supposing you have a platform and you say I Want to permit a firmware update, but only this particular firmware update So then you would you would sign that I say a hash of that firmware update Policy secret is a level of indirection. This says You're not using the password tied to this entity. You're using a password That's contained in some other entity a typical use case of this you would put the password As the password of an NV index and you would tell all of your keys Don't don't use the key. Don't use the password associated with this key use the password That's in this NV index It permits you to have one password controlling a bunch of keys It also allows you to change the password for all these keys by changing one location And then you can also have have multiple users so you can say okay. I need this password plus this other password command parameter hash Hopefully will seem totally useless to all of you. This is a Policy that says you can only use certain parameters So you can say I have a policy for that for this key that can only sign a particular hash or I can only write a 42 to that NV index. It seems Totally useless I'm telling you that because obviously in a few slides. You'll see that it's not useless Policy PCR is perhaps the only one that is TPM specific This is what was in in 1.2 They called ceiling to PCRs and the idea is that you can only use this key or this entity or whatever If the PCRs are in a certain value If there is a if the software is in a certain state and you can put a selection of PCR as you can say PCR 012 and 7 and You specify what digest is allowed Policy and V so in policy secret the this the Value was the password for the NV index Here the value was the data in an NV index and you can do compares you can do greater than less than equal to not equal bitwise operations Typical use cases for this you can do key revocations so you can have an NV index that's monotonically Increasing and you can say I'm authorizing this set of keys until a certain value is Exceeded and that that revokes the key for everyone because we have bitwise operations you can create a Monotonic bitmap index and if you have 64 bits you can do individual revocation For each of 64 People entities whatever You can create an NV index that looks like a PCR in that it can extend and this gives you a PCR That perhaps has a different hash algorithm than your default or perhaps it requires its own authorization You can put a password in an NV index and say you know is the password equal to this And then you can do and term so you can have a range So you can say the count is greater than three and less than 15 so you can do ranges as well Envy written this this one is kind of subtle I think You can have a policy for the first right before an index is written and then you can have another policy for subsequent rights and You would do that in or terms a typical Use of this is that if you have some certain privileged application that's going to do the first right When you read later you can be assured that that privileged User Initialized the index it prevents what we call a redefine attack where if you have an index that you that you trust Someone could try to attack it by deleting the index and recreating the same index with a new with their own Password instead of the password that should be there. Well that fails in this case Because yes, they can do the delete they can create the new index with their own password But they can't do that first right Because they don't have the the privilege to do that first right and because they can't do the first right They can't do subsequent rights Counter-timer if you have a system that has a a clock a clock in this terminology is something that's power that's time powered Time running when powers on let me try that again a clock that runs when power is on so it's wall time or time in this sense is time since a reboot and You can have policies that are linked to those two times or reboot count Typical use cases if you have a service technician doing something on the system you might want to give them privilege But you want to make sure that when they walk out the door. They don't still have that privilege so if you lock the the entity to a reboot count then They walk out you reboot the system and whatever authorizations that you gave them are gone You can authorize until a particular date and time so you can say this is authorized until Sunday Because you have or terms you can say daytime only from 8 in the morning to 5 in the afternoon Or you could say only on weekdays not on the weekends, etc So some of the issues Some of the above use cases require the policies to be created at runtime But you can't do that an entity once you create an entity with a password. That's it. There's no Change the policy. There's no change the policy command and the reason for that is you might want to certify a key Including its policy and after you certify you don't want that policy to change and then we have these Totally useless policies like writing Specific data to an index signing a digest For the people in the TPM world there was this issue of what we called PCR brittleness where you seal something to PCR as Paul talked about this yesterday You seal something to PCR's and then your your pre-OS firmware changes and all of a sudden the unsealed breaks In the 1.2 world the way this was worked around was you had to read the secret All the way up at the application level And then you had to reseal it to new PCR's and then you have the the problem of well What are the trusted PCR values? Is it is it just what I happen to be running? Do I trust whatever's running on my system now? Wasn't very nice But as in all software we solve it by a level of indirection and The command is called policy authorize in words it says the policy has a public key and The entity is authorized by whatever the authorizing private key says is valid so the authorizing key signs a policy and Whatever the authorizing entity signs. That's the correct policy In a flowchart it works like this so an entity has a policy digest just like before a single hash in this case the hash is The hash of the authorizing entities public key, so it's represented here by P now In use the authorizing entity who has the private key calculates a session digest that they trust They sign that session digest with their private key and they send it over to the user Now what the user does is as before they run their policy commands and they get to session digest s at that point They apply the policy authorize if so the the device now has the public key It has the signature and internally in the session it has the The digest so it can do a signature verification if everything matches it replaces the session digest with this value PPP and You're good to go And of course good to go means maybe you're ready to authorize or you can have more in terms after that So how does how does it solve some of these weird things? so writing fixed data to an envy index doesn't work very well, but I know of a use case where a Platform and and this is I guess very common in big systems a platform is shipped with huge amounts of memory and lots of CPUs and Then the user can buy for a certain amount of time use of five CPUs, and then if there's a Crunch where they need to use more CPUs. They can purchase more CPUs so the way that would work here is The authorizer is whoever you're purchasing this the CPUs usage usage from They go you pay them they sign an authorization to update the envy index which holds your How many CPUs you can use? They sign an authorization to update that index that says yes, I can now use 12 CPUs for the next week and Then you you run all your policy commands who apply that authorization and then you can write the index Signing a specific digest isn't that useful, but in this case You can go off to the authorizing entity and you can say I want to sign a particular digest The authorizing entity would say okay and send the authorization back to you I think this of this is kind of Counter-signing like if you go and get a bank check the teller might sign the bank check And then they need to go off and get the bank manager's signature if it's over a certain amount Or maybe if it's not over a certain amount. Well, this would be the same thing. Maybe you're a software development group And you have you have some new firmware and you want to sign that firmware hash But in order to sign the firmware hash you need Authorization from management or authorization from your quality control group So it's kind of a counters countersigning you need one signer to approve the other signer And then in PCRs This is a way to solve the PCR brittleness problem. What happens here is Say you're a platform vendor or or a firmware vendor You have firmware that you know is is good You sign an authorization that says this is good firmware and you Distributed out to out to all the users of your platform and now when they want to unseal They're not unsealing to specific PCRs that are set in the policy They're unsealing to whatever the platform manufacturer says are good PCRs or Whatever your IT department says are good PCRs So it solves the PCR brittleness problem without having to go through this unseal and reseal it also says You can do better than saying what is authorizes whatever I happen to have in my platform now What's authorized is what the software vendor says is authorized or what your IT department says is authorized One more level of indirection. Okay, so so going back up So the problem with policy authorizes that it's linked to a public key and then at some point people came along and said well What happens if I want to change that public key? What happens if the authorizer lost their private key or it expired or You're just switching to a different authorizer and you can never change a policy So later on in the design. This was not an original design, but once people discovered this use case We added a new policy command and this shows an example of how you can add new policy commands And it's all backward compatible. So nothing no existing software broke But if you have a device that implements this new command, which is called policy authorize NV Then you can do additional things and what this says is that the policy is not Well the policy in the in the index is not the policy The policy in the key or the policy entity is not the final policy The policy is whatever is in this NV index. So it's a pointer to the actual policy in the NV index the Trivial use case is when you want to change a policy the very important use case is you can revoke a policy authorize public key by writing a different policy into this NV index You of course have the issue of well, what's the policy to write this NV index, but that could be that could be a higher level policy So that's two use cases for policy authorize NV and to summary All this in a $1 part, which I think is pretty impressive There's only one digest per entity. So for example for shot 256. It's just 32 bytes And I gave you some examples of some business processes But you can go on and on as complex as you like and it's still only 32 bytes The session is opaque. You don't see the into the innards of the session Context from outside. So if we want to add more policy commands That again is backward compatible Assuming that you already have crypto in your system hashing HMAC asymmetric and symmetric key operations Then it's low software overhead if you look at the TPM source code and it's all open source Yeah, there's a lot of crypto that's shared by other things but the The software to do one of these policy commands is actually very small What I mean by proven usefulness is we keep coming up with more and more use cases and you know, I get email from people asking me how to do use cases and Except for that one level of indirection, which we which we added later Everything that we've wanted to do we've been able to do and that's that's a testament to the to the people who originally designed this who was not me But the fact that it's been this flexible over this many years is I think very impressive and lastly It's not as hot as I thought the I don't know what you're thinking now But the first time I saw this I thought this is really complicated Nobody's going to be able to get this or it's going to take a long time for people to get it or they have to read the documentation forever and what I'm finding through mailing lists is that People are people are really getting it people who I never heard of a lot of them seem to be graduate students or even Undergrads with the university so we're starting to play with TPMs. They're coming to me with policies and They understand it and you know that I really feel good about that So that's the talk I'm ready for questions anyone Someone who's not hungry So you asked two questions when you had one last time Does the policy authorize? Have rollback protection because it's only the key that's to be signed. Ah So it can if you want to or it doesn't have to so there were those nonces on some of the previous slides I showed that there is a nonce so you can you can do a signature that says it's only good for this one session Oh, I should say that also a session once it's authorized can only be used once if you if you want to Do something again, you have to start over at zero and satisfy it again If there are no nonces you can replay if there are nonces involved when you reset the session, there's a new nonce and I Think that's what you mean by anti-rollback or it's not no Which which example was in the example that you described where? vendor calculating the PCR's in case of firmware update and signing those PCR Expected PCR values with the vendors private key. I understand. Okay in that example So how do you does that have an element of basically versioning and to give the rollback protection? Okay, so there is not I'll give you two. Okay, you we allow we allow you two questions You have to allow me two answers So so the first answer is By itself, there's no anti-rollback, but you can do things with say counters. So you can say the policy says The policy that I'm authorizes saying says that the counter has to be Less than three and greater than three so you so you start less than three you run the the policy command and then you increment to greater than three and It's satisfied, but you can't use it again because once it's greater than three you can't get to less than three again So by itself, there's no anti-rollback But in combination like I said, there's so much here that you can find a way to do things and that's the way you would Do it so that's one answer the other answer is and when I first went to operating divisions and talked about this They just get in a cold sweat when they hear about no rollback because In a lot of places in the real world If you do some kind of firmware update and it doesn't work the people that are looking over your shoulder The first thing they're going to say is I don't want you to debug it Put it back the way it was get me back up and running and then go back home and figure out what went wrong Okay, so that's the two answers. Yes, you can do it in combination with these monotonic counters And there's probably other ways to do it as well Whether you want to do it while you have talked to the people that are you know maintaining your systems You might not want them to Or they might not want you to More questions So how do you create these policies? I mean, is there some tools or oh great question Will you allow me three answers? So so one If I can go way back here So when you start this session it starts off at zero and then as you send in these policy commands it updates There's a feature in the TPM That's called a trial policy and what the trial policy says is two things first All of these policy commands that comes in are not validated They're just trusted to be good. So no signatures are checked. No passers are checked nothing But you can't use that policy that session at the end for authorization So you can actually use the TPM to calculate the policies and I've seen that I Also, I have some very primitive tools where you're just cutting pasting hexaskey They're not very good But people are actually using them. I'm shocked that people are actually using them now in the TCG They have this vision of Using JSON I was originally XML and I think it's a JSON Where you specify the policies in JSON? There's somewhat human readable And then you have a tool to take that JSON and turn it into a hash It it will be nice if there are tools to generate the JSON if you have to generate the JSON by hand I'm not sure that it's any better or much better than the really primitive tools that I open source But if there are eventually Gooey tools to generate that JSON that'll be terrific the other Thing about that JSON for better and it may or may not be useful will have to see is that you can imagine once you have the policy Expressed in JSON. It's not only good for Calculating the policies, but it's good at runtime where your software say suppose you have three policy or terms Well, your software can present to the user and say which of these three do you want me the software to satisfy? And the user can say well, I'll like I pick a policy B and it can run through that So that might be a very useful Use of JSON what I've seen so far in these or terms is that the business logic for the software Already knows what it's trying to do. It doesn't have to come back to the user and Say that but that doesn't mean that it won't be useful in the future If we there might be use cases where the business logic has a bunch of choices that it can do and Remember you can have ores of ores of ores and in that case the JSON might turn out to be very useful So did that kind of answer your question three times? Yeah Okay, and you know by the way, I don't know how we're doing on time But I'm here all day today and tomorrow It's we're right on lunchtime. So, oh, okay Questions, okay. Thanks, Ken. Thank you