15516
>>: It's really a great pleasure to introduce Carl Gunter to you. He's well known
in a variety of work he did in the security area. He worked for government, with
government. Had good press on some of his projects. He started a company.
I know him for many years, and he used to be at the University of Pennsylvania,
but a few years ago he moved to the University of Illinois, and that's I guess one
of his new projects. Welcome.
>> Carl Gunter: Since this is a generalization of some work that I'm doing jointly
with this collection here of colleagues at the University of Illinois, the purpose of
the talk here is that I wanted to discuss attribute-based systems for security and,
in particular, to look at their illustration in a particular system that we've been
developing.
The goal in part is try to delineate some of the difference between what this
refers to and what you might call classic security systems. And the advantages
of these systems are, you know, in areas of management and formalization and
for new middleware and applications and I hope this illustrates some of the kind
of idea there.
The illustration in here is based on attribute the-based messaging which I'll now
explain.
So an attribute-based message system sends e-mails to parties in terms of
basically a database query is the e-mail address. It's useful for enterprise
systems where you might have access to an enterprise database that contains
information about principles that could be used as the basis for these addresses.
So it's a little bit like a listserv, except the recipients are dynamically determined
by the address and so it's as if you create a listserv dynamically on the fly from
the enterprise database.
So in this case you're going to have something like an e-mail message to all the
female graduate students in engineering who have passed their qualifying exams
be could sent out and it would go to that targeted group.
So the advantages of things like this are, first of all, I don't know about you, but I
get a lot of irritating enterprise messaging that is basically spam but my spam
filter refuses -- where it's hard to filter out.
And part of the reason for that is that people send messages to broad mailing
lists even though they may be only for fairly limited groups of people. And so an
efficiency thing here would be that you could try to target things more precisely
for the people who actually need the message. Like if you needed to send a
message to all the faculty on sabbatical, a typical way to do that now would be to
send it to all the faculty. But it would be nice if you could avoid six-sevenths of
the wasted messages you would send that way, both in terms -- mainly in terms
of the waste of time of the recipient who sees yet another message that they
don't really care about.
Another thing is the exclusivity, which a lot of the messages would go to mailing
lists that you'd like to be a little more refined. Instead of sending it to a big group
send it to a smaller group. Maybe it's something that's a little bit sensitive.
You do this thing all the time. People create listserv things just for specific
groups, because of the sensitivity of the messages.
Here this can be done on the fly. So, for example, all the tenured faculty serving
on conflict of interest committees. Of course, all of this is assuming that I do
actually have a database that can access where that information is available. So
I'll continue to assume that through most of the talk here.
Intentionality is another feature which is it's often easier to describe recipients of
a message than to actually list the recipients. So this is the old logical distinction
between intentionality and extensionality.
So, for example, I might or might not know who the attending and ordering
physicians are for Smith, but maybe I don't really care. I just care that these are
the people that need the message and I don't care who they are. So I don't want
to know their e-mail addresses.
Now, to do this, there are some design challenges that come up. One of them is
access control. So this gives you a great power to hit targeted groups. And so
you ask on what attribute should be able to send a message. So can you send a
message to all the faculty who make more than $150,000 a year who if anyone
should be allowed to do that? Maybe you could figure out who that list is but not
just anybody should be able to send such a list undoubtedly.
You could have like a super admin who is the only person who can send such
messages, but then that kind of wastes a lot of the power here, which would be
really something where you would allow a broader group to use the facility under
a suitable access control system.
Another one is encryption, which is ideally you'd like to encrypt end-to-end so
that the mail relay, if it's compromised, doesn't compromise your sensitive
messages. It's a major technical problem. If the senders don't know who are the
specific recipients, and I gave examples there where you don't know, don't care
or shouldn't know, then how do you encrypt end-to-end for them.
So that's a question that some of the new cryptography techniques can answer.
And a third point and one I'm not going to go into in detail except to indicate a
little bit about some of the questions that come up here, which is you know
should you know to whom you actually sent the message? So you know their
attributes but do you know who they are. And should you know why you got a
message, like what attribute got me on this mailing list?
And then you can see up here things like if you got a message like this and didn't
know where it came from and you answer it, then if you were supposed to keep it
sensitive, who is on the mailing list on and that information will be compromised.
So there's some tricky questions about the information flows that would occur
here.
Okay. So another thing about this is we had an idea on this project that we
wanted it to be practical. They're actually interested in something you could use
as opposed to conjecturing a whole new type of MTA or client that you would
have to use. And so the obvious thing is to implement this in web mail where you
can put all this stuff on a server to do this. But it's interesting to think about how
you could use existing MUAs and MTAs so nobody has to use a special service
to do this.
Or at least the special service they use could be limited in some way, like just a
web page to help them form the address. And then there are questions about
the efficiency of the access control of the encryption.
I'll get to this question here about how you do the cryptography, key generation is
a concern.
Then another point is, if it's too complicated to either form the address or
describe the policies, nobody's going to use it. So it really can't -- or you're going
to use it in a way that causes harm and then people are going to stop using it.
Now, the approach that we have for this is to look at a combination of these two
technologies here. I'm calling ABAC, or attribute-based access control. This has
been around for a while, and I won't claim that it's something completely new,
although I'll kind of focus on some of the differences it has with other things.
And in particular one of our technologies here we were interested in is something
called policy specialization, which is you don't want someone to send a message
and find out they're not allowed to send it by its being rejected.
You want somehow to tell people what they're able to do in advance so they can
never form messages they're not allowed to send. And so when they approach
the system you want to specialize a policy for them. It's a little bit like database
view.
So an individual approaches the database, you give them a view and they can
query against that view. You want something similar to that in this context.
The other one here is attribute-based encryption, which is a relatively new
technology, only a few years old for encrypting in a collusion resistant away
under attributes.
So I'll explain a little bit more about that as I go along here.
Now, this is the part where I was going to try to get a little bit of a distinction
between these techniques and other techniques. This could be a bit
controversial. I'll ask you to indulge me for just a little while before we argue
about whether this is reasonable or not.
But a kind of characteristic way of talking about security is in terms of access lists
or capabilities. And so here you might, for example, have a table and you'd give
a list to the people who have access to the table. So groups can be used for this
to form the ACLs better. And yet in some cases you would prefer to describe the
policy more intentionally. That is it's not in terms of a list of people who have
access, but maybe in terms of an attribute of the people who should have
access.
And then the attributes might be something that you could derive from the
enterprise database. So if you wanted to give access to a table to the managers,
you could have a group of managers maybe manually maintained or you could
have some link between the manager attribute in the enterprise system and the
access control.
So if you do that kind of linkage, it introduces various problems but also various
advantages.
And a contrasting thing here is role-based access control. And one thing I'm
often asked about this is what's the difference between attributes and roles?
And I think it's a tough question to answer because there are things that seem
like they're definitely roles, things that seem like they're definitely attributes and
then a lot of gray stuff in the middle.
So, for example, being the chair of Chian Ching's (phonetic) thesis committee
seems like a role to me, whereas being more than 21 years old seems like an
attribute to me. I'm not playing the role of being more than 21 years old.
And then there are things in the middle where they seem a little bit of each, like
being a professor. So I like to think of the roles as a bundle of privileges often
associated with a task, and we need to perform the task you activate the role
within the session in which you perform the task.
And it gives a variety of advantages in the management of permissions.
But and you have techniques like role hierarchies and definitions to help you
control the rules for what the privileges are associated with the role and who can
occupy a role.
But places often maintain -- argue that they don't want to have to set up any
special kind of role system. And so this is a thing that I run into with
organizations saying we're told we have to use role-based access control but I
don't like having to set up the roles.
Now, so let me try to argue in favor of this, the attribute-based access control
here. Suppose you have Alice she needs to get access to a table in a database.
So a way you can do this with fine grained access control is you put a policy that
refers to the database and it may be the case that it's quite common to take the
ACL, of course, and the ACL is in the database. In this sense it's reflective.
So the database contains information that's about its own access control.
However, you often, in these systems, see this as sort of stratified so that the
ACL is kind of distinguished from the rest of the data. And so the ACL could not,
for example, be modified by modifications of other parts of the database.
And so that process would require some additional steps to make that happen.
Whereas what you often want is a lot of information from the database to be used
in the decision.
So, for example, you would have -- whoops. You would have data about Alice
that's being stored somewhere and then there would be data about the data
being stored somewhere. This might be that Alice is a doctor and this might be
that Sally's data about her patient record or EHR. And then you might have the
relationship between the two data which says that this is the doctor of this.
And so you would like to do the access control based on a combination of these
things. It's not radical concept of course. What you would do is write an
application that manages this access control with its own program logic and it
uses this information from the database to make access control decisions.
So the particular thing here that I wanted to kind of emphasize is that we would
like to go towards more formal models of this kind of thing and of middleware that
can do this rather than mixing it up in application logic.
So the ideal thing would be to have say a language for doing this sort of stuff so
that the security can be separated out into that language and you can reason
about it.
Now, the process of putting the ACL in the database with fine grained access
control is so not sustainable that there are quite a few supplements to database
systems to provide them some kind of system to do more like this sort of thing.
So, for example, the Oracle VPD virtual private databases do something like this.
But then I don't think that it's very easy to take the Oracle VPD system and
reason about it formally and to understand it precisely.
And so one hopes that we can move a little closer towards a more complete
understanding of these kinds of access systems.
Now, looking at the kind of core technologies here, ABAC, there's a lot of
established ideas on how to use attributes and access control. The idea is not
radically new, of course. One that was popular was X509 attribute certificates
where you could have an identity certificate. And then in order to avoid having to
put lots of information on it, you separately have a certificate that binds attributes
to the identity on the X509 identity certificate.
Then you see, for example, in dynamic tokens like [shibilith] tokens carry attribute
information so you can use that for authorization decisions in addition to the
identity information.
And as I was mentioning before, there's a lot of implicit use in application servers
where you go into the database here to get information about the principle. You
go into the information there to get information about the data that's being
accessed and so on.
There are some new approaches. One thing I was kind of intrigued by I saw
recently a trade press article looking at health information exchanges and urging
the use of attribute-based access control matrixes, in effect kind of to draw
access control matrices where the rows and columns are distribution of
attributes. You say doctors have access to lab results. It's kind of a
generalization of access control matrix based on attributes.
Those are limited, though. I would think you could not in such a language
express things like each doctor should have access to their patients. So you
need something more sophisticated.
Another thing here is in trust negotiation work, this sort of popular topic of how
you swap credentials to find out about each other gradually. They've had a fair
amount of work on this use of attributes to do those things. And one that we've
been exploring is to look at transaction data log as a foundation for the reflective
database access control, like I was showing on the previous slide.
Now attribute based encryption is ->>: What's transaction ->> Carl Gunter: It's data log in which there's an operation to change the ground
truths in data logs. They're execution changes the underlying true facts. The
rules change as part of the -- it allows you to do things like suppose you wanted
to represent this thing about if someone ceases to be a manager do they lose a
privilege, then you run the thing and the database can change its actual truths.
So basically gives you a way of modeling both change and rules that depend on
ground truths.
Okay. So now this -- we'll be focusing here on something called cyfer (phonetic)
text policy attribute-based encryption, which is a new set of techniques for doing
encryption on attributes. I wanted to describe the capability of this to you for
those who haven't seen it before.
First of all, you represent attributes as strings. So you can use any string as an
attribute. It's possible to represent types like [boolean] and enumerated and
numerical ranges. And numerical ranges are represented by, like, saying having
three attributes that are boolean for like the first bit, the second bit and third bit.
They're costly to do the numerical attributes, but many things need numerical
attributes.
Then you have an attribute authority who issues individual private keys to users
based on their attributes. So I would get the professor key, for example. And
then you encrypt using something called an access structure which is a tree with
thresholds. So, for example, if you have two children and the threshold is one,
it's a disjunction. If it's two, then it's a conjunction.
And you then decrypt -- you encrypt this using public parameters and then you
use the private keys in order to decrypt if you happen to have a satisfying
collection of the private keys.
And the hard part about this is the protection against collusion. So if I send a
message to tenured professors in computer science, then an assistant professor
in computer science can't collude with a tenured professor in ECE to get the thing
decrypted.
In particular, the way the private key is -- the faculty key that I have will be
different from the faculty key that another member of the faculty has. Because
we have an individualized attribute key.
I won't go into the details how the cryptography is done for this talk. Now, let me
turn back to the ABM system and talk about that a little bit.
So there are three key policies that you get in the ABM system.
So addresses in our case, I'll talk about our design here, but you could have
done this different ways, are disjunctive normal forms.
And you have literals that assert equalities or inequalities. You can write things
like the position is faculty and the salary is more than 150,000, for example,
would be an address.
Then this is what we call a receiving policy. It says who you want to receive the
message. Then another step as we talked about that it's not possible to let
everybody send all these kinds of messages is what you would call the sending
policy. And what you do here is you use ABAC rules to define the attributes a
party can use in an address.
And here it's kind of a tricky design. We did something fairly simple in order to
keep the thing more deployable or easier to write. So you can imagine a
complex access control system so that any combination you might make to
create an address would be its own individual access control.
Instead what we do we simply have a condition that says whether a particular
attribute can be sent to a particular value in a message that you send.
And then you're allowed to combine those in any way you wish. So, for example,
if I can route on faculty and I can route on gender, then I can always, if I had
been able to route on those individually, just send a message to both of the lists,
with some possible redundancy, what's new here if you would be able to route on
the intersection and send a message to the female faculty.
So there's some question as to whether that would be an acceptable policy all
the time or not.
We didn't think of really compelling examples where we thought it was
objectionable. Okay. So then you can that way control who gets to receive the
messages using attribute-based access control based on conditions drawn from
the enterprise system.
>>: If I understand you correctly, the condition defines which attributes are
available to you.
>> Carl Gunter: That's right. So that condition right there might be faculty can
send mail to faculty, that would be an example of a role.
>>: So you have conjunctive conditions involved in the attributes, (inaudible)
message for the properties for each attribute?
>> Carl Gunter: If I had over here a conjunction like if, say, faculty and tenured
like that, then it's what's on this side that is the encryption condition. See? So
this is my permission over here and this is my address.
But if I want to send to the female faculty, I can encrypt under both faculty and
female. That's what the access structures give you with the thresholds.
>>: If you have and/or combinations, then the other can be (inaudible)
>> Carl Gunter: Yeah. In fact, one of the main things I wanted to show you for
those interested in the cryptography aspects, I think this is one of the best new
practical applications of attribute-based encryption systems. And we have
performance numbers based on CPABE to show exactly what the limitations are
for use in this application. I'll show you some of those.
So, yeah, the more complex the policies are, the more it costs you to do this
stuff. I'll show you how we estimated that. That was one -- I'm glad you asked
because one of the main things we did in the project was looking at these
performance scalability questions. I was afraid I was going to bore everybody by
showing it to you. Maybe I'll just bore some of you.
Let's go into reading policy here. So the attribute authority issues keys using the
enterprise database like it looks up in the database whether I'm faculty. And then
it says how long it thinks I can be faculty for and gives me an expiration key.
So, for example, you can say faculty and 1998. I'm sorry, 2008. If you say
faculty and 2008, then I'll have to have both sort of the 2008 attribute and the
faculty attribute at the same time.
So you can issue a group of keys and issue an expiry attribute and if people want
to use expirations on things they can crudely expire things.
And then you use disjunctive normal forms to define the reading policy.
And this is the target encryption you're going to use on the messages. So this is
going to provide you with your protection against a compromised MTA, for
example.
Now, the system looks like this. I wanted to give you a high level architecture
and then do the three protocols. The high level architecture is that you have your
usual MTA. In our case this was the University of Illinois's exchange server. In
other words, no change to the MTA at all.
You have a web server that supports ABM. You need a little bit of client software
for the keys but not for the MUA. The MUA in our case was we used several,
outlook and Firefox and so on.
Then you need an attribute authority to issue the keys. That we had to code
entirely ourselves.
Well, we used a library from SRI for this. Then they have ABAC-end support
system that does everything special in such a way as to try to avoid changing
things much. In particular, on the back-end you have of course the enterprise
database which you need to access for the attributes. And then our particular
ingredient is a thing called the ABM server up here which is kind of the guts of
the system.
And it uses a policy description, a decision point which may be on the ABM
server or it may be somewhere else. So this policy decision point is the thing
that holds the policies for like who can send messages.
The system is divided into three protocol groups that we call the policy
specialization path, the messaging and address resolution path and the attribute
keying path.
And I'll just give you a sketch of how each one works. Particularly to show how
the system avoids changing the existing enterprise system or client since that
was one of the major deployment objectives.
So in the policy specialization path, this is how you compose an ABM address
and also get your permission to send the message. Okay? So the way you do
this is the sender goes to the enterprise authentication server and gets a token.
At the University of Illinois we have some special thing called Blue Stem that
does this. It could be Curborose (phonetic) or something else.
So Samel (phonetic) or whatever enterprise is used.
Then you go to the ABM server with this authentication. And the ABM server
then goes into the database here and derives using the policy decision point.
Here it gets information about you, your attributes. Then it refers them to the
policy decision point which comes back with your specialized policy, what you
can do, represented as a web page, in our case, where you can kind of click
things saying this and this and this, and within -- this or this and then within those
this and this and this. So fairly simple to use.
So it would be easy to cobble up the address for female faculty. That's not hard
to write. For me to use that is easy.
In its guts it becomes an X path. And so the e-mail addresses will be basically X
path expressions. This one is the address resolution. This is how you send
e-mail. So it's one little compromise in here to avoid changing the MTA and
MUA. And it goes like this which is that thing where I got the X path, what I do is
I save it into a file. We call it a .ABM file. I'm sure it's taken already. But the
.ABM file is your address. And so what you do is you send your message to
uiuc@, abm@uiuc.edu, a special address is allocated for the ABM messages.
You have an ABM attachment that's then taken to be the address.
So the address is then resolved by the server using the database. And so in the
address list is the female faculty. Then you would go in here and find the female
faculty. They would be returned as a list of addresses. So this is your dynamic
listserv.
Then this would be sent with Microsoft Exchange through an interface that's
available for that that basically creates a dynamic listserv for just this message.
And then that's sent out to all the recipients like this. The encryption is done at
the sender, basically by encrypting a file. You take an attachment and encrypt it.
We have a binary function. All this fairly clunky stuff, command line thing.
But what you do you take your ABM address file that you just created together
with the recipients that you want. I'm sorry, the ABM address together with your
message body and then you run this function and it uses this package to encrypt
it.
Then that's sent out and on this end we have software to decrypt it. So I'll show
you performance numbers on that stuff. Is there any question on this one.
>>: Back to his question. If you can receive this, if your name is Bob or you're a
female faculty member, your encryption will branch? You have to encrypt it both
ways because Bob is not a female faculty member, doesn't have access to those
keys.
>> Carl Gunter: Yeah, that's right. Right. So that's the magic of ABE it does that
stuff. I'm black boxing it mainly for this talk because I don't work on the
cryptography stuff. But I appreciate it.
So it does for this application something that nothing else could do.
So you're right to hesitate on this and say how would you actually do that. And
so that's what it will do.
Note in particular, too, for like sending to listservs, you know often what you do is
you trust the listserv to have all the keys of the recipients, which in a way throws
out the baby with the bath water, because I mean part of the point of end to end
encryption is you don't want the thing to remain on the listserv in clear text.
So trusting the listserv to do all the encryption seems kind of pointless.
And so here you encrypt end-to-end to a collection of recipients that you don't
know who they are.
>>: (Inaudible) encryption.
>> Carl Gunter: Yeah. So you send out one copy, but the attributes allow you to
decrypt it. So you don't have to do as -- in S MIME if you would do this, say there
were 100 recipients, I don't know if there's specialization of this technique, but we
would typically like have a hundred encrypted session keys included with the
message and send it to all of them and they would find their session key.
So in this case you don't have to do that. So when you come here to the attribute
authority, the receiver comes to the attribute authority says I need my keys, okay
so it goes to the database and it gives them their keys, back up here to the
receiver and I'm skewing a few little security points here. The authentication to
the AA -- I already talked about that. The enterprise authentication server does
that.
I'm assuming here that you also have an identity certificate for S MIME purposes,
like an X5 or I9 cert. You use that to decrypt the message and get your copy.
So I have my own special faculty key. I'm not sure if we thought that Bob was an
attribute. But if we did I'd have my own special Bob key as well.
So then the message from the MTA that you received is this decrypted using
those attribute keys. Now, looking at this process, the obvious question was how
big an enterprise could do this? And so what we wanted to do to try to calibrate it
was to go for a middle-sized enterprise with ordinary machines.
That's something the way a university of Illinois would be because your e-mail
server is a fairly ordinary machine. Nothing special. Maybe not like a super
computer or anything.
So we were interested in like how much could you support with just kind of
ordinary machines.
So I don't describe the machines here, but the kind of stuff you might have on
your desk. So we wanted to measure the costs on each path and estimate the
latency for mid-sized enterprises and conjecture here what kinds of policies might
you use.
Now, this is one of the hardest parts. And I partly push -- I don't know if any of
your are interested in this, but I do a lot of policy stuff and scalability. The
question you always get is is this really scalable.
The answer is it's hard to answer because nobody uses ABM now. So how do I
know what kind of messages they're going to want to send? And so we had to
come up with some idea how we could crudely test this given that we have
nothing to go to and say, oh, here's our experience with lisservs and that's going
to tell us how to do these dynamic ones or whatever.
We used this Bethencourt (phonetic) and Highswater (phonetic) implementation
of this cyfer text policy ABE library for this.
They did a first version for us we used got some performance numbers, found
some ideas on how to optimize. Told them. They did us a second version of it
including more optimizations, but there were trade-offs between encryption
efficiency and key generation efficiency that they exploited to improve in a
direction that turned out to be the opposite of the direction we needed.
And so their second version of the system was slower than their first version,
which basically says that you have to kind of look at the applications to tell what
you need to optimize on in this space, and we don't know this yet, I think.
A big bottleneck here is key generation. Okay. So this is the policy
specialization times. And so the way we did this was for lack of any more
inspiring way, we would basically generate random policies. And so you would
say something like I want to have five terms and I want each one of the sub
terms, each one of the terms to have five literals or up to five randomly chosen.
And so you would get like a cross section of this depending on what you chose it
would generate a certain collection of random policies.
The paper has details but what popped out of this was we got 143 rules in this
random manner for one version. Then 282 rules in the next version and so on.
So we got this rough graph which shows if you wrote 143 rules then it would take
less than a second to decide what the user's policy is. Whereas if you're up here
at 674 rules, it might take 12 seconds to do that.
So somewhere in here there's some kind of like patience gap where you might
say you gotta optimize this or people are going to be, you know, fed up with
waiting. Or you might have to put in something we'll send you your address by
e-mail or something like that.
And so you do have a bottleneck here. It's not clear to me you're likely to have
674 policies -- 674 rules. So I thought this was kind of on the high end. 143 was
not a bad estimate for what you might have.
But then, again, who knows. So it depends on the organization and what kind of
attributes we're talking about.
>>: The shape.
>> Carl Gunter: What?
>>: Shape of the curve.
>> Carl Gunter: Yeah. It's kind of that crudely linear.
So now we did studies with the database. We did two databases. We did -- this
was Microsoft's SQL server, SQL, and we also chose the Microsoft 2005
because you could also do XML with that.
So we wanted something that would do both. So this is with Microsoft SQL
Server. We did it in two versions, with the access control and without it, to try to
at least look and see how much are you paying for doing the security stuff.
And the security introduced an overhead here that you can see. This is sort of
95 percent confidence range. That's in milliseconds. And this is with an
organization of 60,000. When we ran our random thing, the average list size,
that is when you're sending one of these attribute-based messages the average
list had 351 people on it.
And so to do the resolution of the list, to find those 351 people took between 180
and 359 milliseconds, which seems quite reasonable to me.
On the other hand, the X to know 1 wasn't so good. So there you see here this is
in the several seconds range. So your through-puts are going to be hit pretty
hard by this. I'm not sure you care much about latency here. Because this is like
I send the message. If it's delayed by 7 seconds, you know, how urgent could it
really have been, right?
So on the other hand through put might be an issue. You might need a highly
provisioned -- part of the reason we were thinking of this is that when you
imagine the useful information in the organization that could be used for the
messages, if you think broadly of everything as opposed to just what's in the HR
database, it makes the thing enormously more useful.
And you see lots of specialized applications now have bits of this kind of logic in
them, like schedules have this, where you invite participants and so on.
And so if you could really mine all that stuff and view it under one conceptual
framework as an XML database, it would make the thing enormously more
useful.
So that's why we thought this thing would be interesting. We saw some
presentations people gave on the idea of like using XML to characterize the
entire information. I don't know if you work on this sort of thing or not.
But look at the entire information infrastructure of the organization and give it an
XML schema, and then you have like all of the underlying databases would be
their different diverse technologies, but XML would allow you to unify those all in
a single thing.
Now, encryption is done on the client. And so I don't think it's very
performance-concerning. We do have numbers. So this is -- if you have a lot of
relation literals, then you're going to cost yourself for that. This is equality literal.
So we can see here kind of the high end. If I have six equalities and six
relations, more than 21 years old for this and is a faculty member for that, then
it's going to cost you about 4.63 seconds on average to do the encryption, which
maybe it would try some people's patience, but I don't think it's that bad. And the
decryption times were about a third of a millisecond. So almost negligible.
>>: If you have this running on like a source or something like that -- send
message to if you want to send to the faculty that would be an equality that took
half a second. 500ths of a second.
>>: (Inaudible) the use of the same ->> Carl Gunter: That's right. That's very simple. So there's just one key in that
case, right, as opposed to a complex of keys.
So that seemed actually quite good. This is with a slower version of CPABE.
Like I said, they changed it around. We were finding this was no problem. It was
the other stuff we had bottlenecks. I'll show you that in a minute.
So this is the generation of keys. And this was more significant. So here this is
with numerical attributes and boolean attributes and we're doing it again from
zero to six. But our system, our underlying system had 100 attributes.
So we're talking about like this is assuming that suppose only six attributes are
used in a given message, then I only need those six keys.
So it's kind of reasonable to have a small number. So although there are 100
attributes maybe I don't need all 100 at once. If I did need 100 at once then you
could project what these figures might look like.
If you're going for like six of them you can see here a few seconds is required to
get them. And so I'm going to the server asking for these six keys. It will take
me a few seconds to get them.
>>: Server generates the keys at a time ->> Carl Gunter: That's right. This is for on the fly. But you could have it
generate them in advance, maybe. There's no problem having it generate them
in advance.
>>: So this is just the sender will log in and you would get dynamically with the
keys and for the encryption process.
>> Carl Gunter: No, this is the recipient. So I get a message, and it's been ABM
encrypted or ABE encrypted for ABM. I say I need the keys for this. We didn't
do anything fancy with this, and there's a little bit of a thing here which is you
know remember I said earlier there's a question whether you know you're on a
list.
So one of the decisions we made was you know whether you're on a list because
it has to tell you what keys you need. And so in particular the access structure
under which this thing is encrypted has to be included in the message.
In addition to the X path. So anyway the information about or rather derived from
the X path. Anyway, you would be able to tell why you got the message. Or you
could have gotten it in several different ways. Might be both you're in one group
and another.
But you would then be able to choose the collection of keys with which to decrypt
it.
So this is measuring how long it would take you to get them if you got them just
at that point.
So it gives the kind of general measure of how hard this ABM, the attribute -- this
is one thing nobody has worked on that I know of is the performance concerns
for an attribute authority if you would have one for attribute-based systems. That
is attribute-based encryption. This is giving some clue. So what these are is
different measures of the window of vulnerability that you might have for the
system based on how long am I going to be able to keep a faculty key with an
expiration even if I'm not a faculty member anymore.
So I've done some heinous crime in the classroom and they've kicked me out
immediately, I still have this faculty key.
Now, I'll note that just because I have the key doesn't mean I get the message.
And so there's a great deal of risk mitigation here, but if you're really paranoid
about it, then you want short windows of vulnerability. Like maybe you'd like me
out of the system today.
So if you want me out today then we can support an organization of 10 users for
this kind of thing, and so this is -- I'm skewing a lot of details here about like how
big -- a lot of parameters are missing from this chart. But the point is that, you
know, if I'm insisting on refreshing the keys every single day, then for most
different combinations like this is 30 string attributes and 10 numerical attributes,
if I have to rekey that many per day per individual across an enterprise. Like I
said, this is a 60,000 person enterprise with 100 attributes per person, then I
would be able to do 10 of them in a day.
Sorry I'd be able to do 10 users. It's not 60,000 people, it's the -- I can support
10. I'm sorry is it in thousands? 10,000 users. Yeah, that was kind of important,
wasn't it? Pardon me. (Chuckling) it's more scalable than I'm giving it credit for.
So up here you can do quite well of course if it's just a month. That's not too bad,
but I would say this one is representing a real bottleneck.
If you wanted to rekey every minute or something like that, that would greatly
impact the capability that you would have.
So I do believe that rekeying on a monthly basis should be reasonable because
you're talking about the rare instance where someone is revoked and they keep a
key for messages that they're not supposed to get and you're worried about their
breaking into the system and getting other people's messages for a month. So I
don't know. I guess it depends on the organization. May depend on the
attributes, too.
>>: Seems like the reverse problem was, if I have an unexpiring message and
you have to make a (inaudible) fix on the key server, you risk invalidating all of
those messages.
>> Carl Gunter: Oh, yeah, that's points one of the key aspects of the system
what about keeping old keys. Right? I go away on my trip to climb Mount
Everest, and I get back and my e-mail in bin is full of messages I can no longer
encrypt. So what about how you're going to keep all the keys.
You have really old messages and it's not issuing those kinds of keys anymore or
whatever.
A logical way in this application to do this it seems to me is to have a reasonable
expiry on how long, how many keys you're going to keep. And to do something
like when I read a message I reencrypt it under my identity key and put it back in
the database.
So that way you don't keep things in the attribute encryption in the system. So
you just have a reencryption of that. So your old messages are always
encrypted under your identity certificate. One could imagine lots of ways to cut
that up depending on what kind of size you're trying to support for this.
All right. Now, let me talk a little bit about the security and privacy analysis of the
system. There is a question of how you enforce these policies for sending,
receiving and reading.
An important one, in the first version of this system, we had the idea that we were
going to sign the ABM addresses and then you would send something with a
signed ABM address. And then it would have like a time stamp on it.
And this would help us avoid things like trying to rely on the security in the
exchange server or whatever it is, making sure that the user who logged in is
using their privileges to send the message out.
And so we found after the performance numbers that you could really probably
do this more easily just by letting the ABM message, the ABM messages be
public and unsigned, that is, anybody could put them on the web page and do
whatever they want with them.
And then you issue them to people to help them make them. But then you also
check them when they send the message.
So basically they're checked both at the time they're issued and at the time
they're sent.
At the time they're issued you only check them to help the user make sure they're
not composing something that won't get delivered.
So these are always checked dynamically using S MIME. So what you do is you
authenticate to the ABM server using S MIME and then the S MIME uses that
name to do the check to see if you are allowed that send policy.
Now, the vulnerability windows are actually rather interesting. One thing is when
something expires, the receive might be a subset of the read. In other words,
more people might be able to read it than could receive it. Makes no sense to
have more people who can receive it than can read it. Kind of silly to do that.
You just receive an encrypted message you would be frustrated to find you
couldn't decrypt.
But it makes sense in many cases to have the read policy exceed the receive
policy. And in fact, this is one of the most interesting things I thought in this thing
that I haven't really investigated much. And I'll just give you a little example.
Suppose you're sending a message to Sally's attending physician. Then you
might be able to encrypt under those attributes. But it might make more sense to
just encrypt under the doctor attribute, since in most of these enterprise
applications the doctors have access to everything anyway. And you just need to
make sure that that is not available on an external server to a non-doctor in your
organization.
So having reading policies that are possibly way larger than receiving policies
might be the most practical way to do this. It's just that you'll need a whole new
raft of policy stuff to figure out what that should be.
>>: Depending on how e-mail server is implemented, is there any way for sender
to cache, suppose like change it. I can potentially compose an e-mail in my draft
folder with the current policy, but send it later when I may not have otherwise
access to that particular policy.
>> Carl Gunter: Now, for the client, caching is no problem. So it helps me form
a file which is like an address I can put in my address book. You can imagine
extending the address books to include ABM addresses.
So like the female faculty, if I need to regularly send to them, I could have that in
my address book.
The caching on the other end, like I want to kind of remember that this guy has
permission to use that tool to avoid having to recheck it, we did that at first and
then decided that we didn't need to.
A principle that we tried to apply is whenever possible let the database do the
optimizing. And so we were trying to assume that if something is frequently
requested from the database, the database is smart enough to know how to
make sure you can get that quickly.
So if people are often routing on faculty, female faculty, then the database should
be able to tell you the female faculty quickly.
Maybe people who know more about database optimizations can tell me if we
were unwise in that reliance. But that was a principle we tried to follow.
>>: So for this particular example, if I compose an e-mail based on the current
policy, and then put that e-mail in a draft folder ->> Carl Gunter: Yes.
>>: -- 1 month later I can send that e-mail.
>> Carl Gunter: Yes.
>>: At that time I've got to recheck the sender to see if ->> Carl Gunter: Yes. If I sent it -- I don't have to go back to the ABM policy
specialization system. But I have a risk that it will be rejected. So if it's been a
year that it's been sitting in my draft folder, then it might be I no longer have the
privilege to send that because of possibly policy changes at the organization as
well as changes that might have occurred from my attributes.
So in general I would guess what's going to happen is it's again one of these
things I don't know what people are going to end up using something like this for.
A likely kind of thing is sort of CRM-like messages where you need an
administrator or someone in charge is broadcasting a message. Seems less
likely to me that it's going to be for discussion groups, for example.
But then what would happen is I'm a person who often needs to tell something to
the female faculty. Then I would just keep that address and I would know
whether I continue to have access to it.
So if the MTA or the ABM server is compromised, you lose who sent what to
whom but not the contents of the messages. That's what the ABE does for you.
The clients, if you have a compromise client, you lose the information sent to that
client and anything that they can get through a compromise that can use their
keys. If you get two clients, you get the union of the two clients but no more than
that because of the collusion resistance.
So if I compromise a CS faculty member and I compromise a tenured assistant
professor in CES and tenured professor in ECE, I still don't have enough to get
the messages to the tenured faculties in CS. So those productions are made.
And then concerning privacy, this is one where what we did was when we were
forced to do something because it seemed like we needed to to make this work
we did it. Otherwise we didn't try to do anything fancy. And our implementation,
you don't get to know who the recipients are. But you get to know why you
received a message.
Now, here's a little bit of the related work. Attribute-based addressing for -actually, we found a patent on this. Patent application. I don't know if it was
successful. So this crowd right here attempted to patent attribute-based
messaging they called it attribute-based addressing. It's exactly what we're
proposing here which is their application was CRM. And so they wanted, of
course, if you're doing CRM things you wanted your address to be as targeted as
possible so as not to dull your customers's interest in the messages you're
sending.
So they proposed an integrated system for using a -- now, what's very different
about this is that although they're using ABM they didn't do anything with
security.
They don't even have a security concern in a sense because it's like someone
who has his CRM list and he's going to be able to do what he wants with that.
So what our work adds to this is the security dimensions, particularly.
And intra enterprise use.
Role-based messaging for medical applications is another thing that's quite
close. I talked about the difference between roles and attributes. This is quite a
gray area. So you might think of some roles as being determinable from
attributes, and so when you have a way of getting a role from an attribute, then
you can use our stuff to do role-based messaging.
If you think of the roles as something outside the system that you can't get
access to then you might not be able to do it.
Then there's ABAC for trust management, I mentioned ABE for imposing access
controls. Part of the logic for ABE is it can take your access control system and
use encryption to impose it on somebody else.
So like if I hand out some data to someone else, then the encryption enforces
access control rules on that data.
That's sort of what we're doing with the MTA in effect. Now, here's some more
work we've done. We had a project called WS mail, which was one of the
earliest parts of this. It was looking at what would happen if you redid e-mail in
terms of web services.
Particular study here was to look at using .NET to implement our new version of
e-mail in which messages are not using SMTP, they're using SOAP. They're not
using S MIME, they're using XMLD SIG and so on. So we built a WS mail
system on .NET for this and studied performance numbers, reasoning about
security. We also did this system adaptive policies which was e-mail where you
can explain what your policy is to public and then they can react to it. So if you
don't take attachments above a certain size, you can tell them so that they don't
have to send a message and then call you on the phone and ask you if you got it.
And then another one was shibilith RSS. We built a version of shibilith to do
CDA health alerts where you go and you give them your attribute credentials and
it determines the feed you get.
So if you're like, if there's a health alert about a possible bird flu outbreak, you
could have that feed go to just say certain kinds of doctors that would be the
ones you would first inform of something before you scare the public with an
announcement.
My ABDAC is an effort to use existing database trigger mechanisms in particular
in my SQL in order to implement using fine grained access control
attribute-based access control.
In other words, try to make attribute-based access control to be implemented
with the existing database support mechanisms.
Reflective database access control I mentioned already. You can Google us
here. I wanted to say a little bit about the application spaces that we were
interested in to give you an idea how we're trying to test the work.
One of them is energy management systems. So this is an interest of mine that
I'm not talking about today.
Particularly security for the power grid. One of their big problems in that space is
operator, vendor access to substations so they can check -- it's a little bit like I
think my PC does this call home to Microsoft to check for updates and so on.
It's hard to do something like that in the control system space because of their
efforts to isolate the systems.
So a big problem there is to figure out how you're going to update these systems
in a reasonable way.
So this would be allowing you to do things like Sweiser (phonetic) Engineering
Lab engineer gets an attribute that allows him to get a role to go look at the
configuration of a Sweiser Engineering Lab relay in a substation.
So trying to develop a system to do that kind of thing. And then healthcare is an
obvious application area where we might be able to apply this.
Doctors really don't want to worry about things like who gets the message. So
there's fairly -- I mean they definitely want it to be got to the right people but they
would prefer themselves not to have to know the details.
So we have fairly substantial systems in which you might say quote something in
voice text and then someone transcribes it and figures out the rules for where
that message is supposed to go and then how the thing is supposed to be
checked.
And so one thing you might hope for is more automation. So if I have some sort
of rule that says that this has to go to the attending physician, the primary care
physician and the ordering physician, then it would be nice if you could just say
that as opposed to like trying to resolve who those are before it makes the
message.
On the other hand, a major trend in this space, as I went trying to sell this idea to
people, a major trend in these HIEs is to try to get out of this messaging
orientation.
So what they want to do is to, many of you probably know more about this than I
do, but they want to take all the data, put it in one place and give everybody
access to it. So like a state might say all the people in the states are supposed
to get their MRI readings from one place and then we put all that data in a
database and then everybody gets access to that database. And this is how we
get rid of this messaging stuff.
And this runs into legal challenges with privacy. You're creating a big pool of
people's data that can be accessed by lots of different people, unless you put an
access control on it.
And so there's some interesting questions about how you're going to describe
that access control. That thing I quoted earlier about the access control matrices
written with attributes was something I saw in the trade press about HIEs
suggesting to people that might be a good way to write down their policies.
So the e-mail messaging based on attributes is feasible and deployable in
mid-sized organizations.
We didn't try to find out what would happen if the organization were really big, but
I think it could be done. We did in the case of shibilith RSS think about what
happens with interdomain issues. But here a lot of that stuff of course is related
to the possibility of having attributes that mean something to both me and to
another organization.
And so once you figured out how to do attribute mapping, then maybe the
scalability things can just be sort of put on top of that. Like if you have two
organizations of 60,000 and we've proved it's scalable to 120,000 then it will
work.
I think these policies, they're kind of simple, but I think they're intuitive. I mean I
don't have any trouble giving many examples of these things and people give the
examples back to me including some clever ones. I gave this lecture last Friday
and it was at University of Texas at San Antonio. And someone asked if they
could send an e-mail message to all of the faculty but one, the one that they're
complaining about. [Laughter] so they want to know if the system could support
negation. This is one we never thought about. But yeah, maybe you want one
like that.
So there are kind of a richer collection of policies from messaging that you might
imagine here. And the examples can be quite intuitive. That's it.
(Applause).
>>: More questions?
>>: As you work on your power system example, it seems like you're going to
describe exceptions and denies become very relevant.
>> Carl Gunter: Yeah, now, the way that -- so here's one of their big problems is
they don't want to put like the permissions into the Edge devices, because then
they have a big management problem with their permissions in the Edge devices.
They want the permissions to be more like Curborose (phonetic) like or
something more centralized. So we're trying to develop an approach in which
you have a policy decision point outside of the substation and then the policy
enforcement point is the relay so that is, that Sweiser's relay does the roles. And
our decision point is based on attributes and it does the decision. So that's the
architecture we're aiming for.
So this stuff, this is fairly rudimentary, right now, what they have, with kind of
heavy perimeter protections and then fairly vulnerable edge devices. And so our
project, the more global project, which I'm not talking about today, is to look at
ways of trying to make the thing more protected at the edge rather than so much
dependent on perimeter and isolation protections.
>>: I think I understood that all of your attributes right now are being pulled from
a database.
>> Carl Gunter: Yes.
>>: Trying to determine the recipients of a message.
>> Carl Gunter: Yes.
>>: Have you done a study about a combination where say the majority of the
attributes are from a database but some are dynamic? The example I have in
mind is office server bank in Switzerland or many offshore banking can look at
the customer records within the borders of Switzerland but nowhere else in the
world would you look at the characteristics to determine the recipients or
introduce some dynamic attributes that could introduce deny situations?
>> Carl Gunter: I think so. The sending policies perhaps do that. You might
have an attribute of like location.
>>: The location is something that's dynamic. It's not just obviously if you have
location and they were static.
>> Carl Gunter: Yes.
>>: Today I can but tomorrow I can't because I crossed the border.
>> Carl Gunter: You have window of vulnerability challenges with the keys, but
with respect to the attribute checks, it's not that hard. So provided the system
knows. It has to have some way of knowing. So assuming it knows where I am,
I think that that could be programmed in, yeah. I think we can do that with what
we have now.
>>: Some other examples in that same space are the health of the machine that
someone is accessing, do they have virus software, do they have all kinds of
things that can be an attribute security and something in the organization.
>> Carl Gunter: It's interesting -- what we did we got from the University of
Illinois a description of its HR database contents. And then we kind of made up
some other stuff, and we did some statistical things saying here's what we think
are the likely -- some attributes everybody has. Some are very sparse and we
did some estimates from that.
But we didn't focus on this question of like very dynamic attributes, like location of
the sender. So I mean the Switzerland ones I know about that they're very fussy
about where you are when you do your transactions banking-wise, for various
international legal reasons and such or actually Swiss legal reasons, I believe,
right?
But we didn't have a long list of such things. There were other ones, what I'm
thinking of the application areas, military folks kind of resonated with this,
because you might send things based on things like security levels. So you
could send messages based on recipients that had levels that relate to yours in
interesting ways.
So, yes, I really didn't look into any detail in that but it seems interesting.
>>: So with respect to the attributes which can be used for dosing by the sender,
is it something like just survivor (phonetic) groups or is it more like you can send
it to people who have say (inaudible), is it a aspect of that.
>> Carl Gunter: It could be. Could be. Yeah, so if you got a set of rules that
said you had complete permission, then the way the thing would look is that you
would have a list of all the attributes in the system and you could select. And
within each one of those you could go in and that's the disjunction. And then
within each one of those you could select a conjunction.
>>: With the server (inaudible) the address.
>> Carl Gunter: That's what I'm talking about. This is the addressing capability.
So if you had like rules that signed lots of attributes to people they would have a
big web page with 100 things they could work with at two levels.
>>: You talked about using BP. Did you look at any other features for other
databases.
>> Carl Gunter: Yes.
>>: DB2 or anything like that?
>> Carl Gunter: Yes, we have a paper on that and it has a list of the ones that
we checked. So we started with Oracle VPD, and what we were interested in
was the idea of I create policies in the database and you create policies in the
database and then how those interact. And you get some very interesting
problems with respect to I run a query at either my privilege or your privilege, but
you get to say my privilege but you get to rewrite it in the VPD. And then what
happens is that it can leak information of mine because you're now running at my
privilege.
We sent this to Oracle and they, at first, thought it might be a bug. But then they
wrote back and said: Well we just have one database administrator and
everybody trusts him. So this isn't relevant. So there's a -- I understand why
they do it like that, but as a scalability question of wouldn't it be better if you could
have policies that are more distributed.
And the other point was that we weren't doing it right. So we hadn't programmed
it correctly. So there was a different way of doing it we didn't know about, which
made us appreciate. It is tricky. And so that's why we wanted to look at this
formal languages stuff.
>>: You said you looked at other things.
>> Carl Gunter: Yes. Microsoft's one has the same issues that we found and
one or two others. So that we checked -- this is Lars Olson the student working
on this he's the database person I told him to look at the major vendors to find
out as much as possible whether the same problem would arise in the other
products.
>>: You have links on your website --
>> Carl Gunter: No, that's a paper we just submitted to CCS. But I'm willing to
share it with you if you like. If Lars doesn't mind. I think he would be happy to
share it.
>>: Do all attributes have parameters.
>> Carl Gunter: No, we didn't consider that. In fact, one thing we did was we
first did a simple version with X path. So the idea was just to do no more than X
path. Then they came out with the encryption stuff and we found that -- we told
them you can do exactly X path. So your encryption can take these X path
things and encrypt with them.
I don't know, there might be some generalizations. They're all the time working
on generalizations, like at CSS. There was one on revocation. So this thing has
a very simple model of revocation and then we work with these vulnerability
windows. But there is no revocation in this case.
>>: Absorb roles in the attribute.
>> Carl Gunter: I see.
>>: Chairman of the committee for the attribute, chairman of the committee.
(Inaudible).
>> Carl Gunter: Yeah.
>>: How about works four equals (inaudible) everybody who works for Bob
except for Frank. (Inaudible).
>> Carl Gunter: Right. Those are appealing example of that, everybody but one.
(Chuckling).
>>: Your key server has to go, would your key server generate a whole new
key?
>> Carl Gunter: Yeah, this is one of the things I thought was kind of crazy about
the system. If you look at some of these more complex ones, it's clear you don't
need all those keys. Right? So that's why I mention that thing about doctors,
which was many cases it just seems like it makes a lot more sense to have the
reading policy be a big envelope around the receiving policy. And so that would
be a kind of next generation of work on this is to figure out how you describe the
relationship between reading and receiving policies.
>>: In terms of the performance, I'm just curious, if you had to try to maintain the
(inaudible) table more on APN policies and (inaudible) are required to raise that
e-mails to send to that (inaudible) policy.
>> Carl Gunter: You mean have we tried to simulate a system over time?
>>: No, cache result. The run time resolution to find out the list of recipients, find
out the keys.
>> Carl Gunter: No, we didn't do anything like that. It would be -- you know, it
was something we got up to the point where you could actually just use it at the
University of Illinois.
But if you really were going to use it, you'd have to make this a lot more
streamlined. It's like using PGP. It's very, very clunky and tiresome, if you use
this command line encryption and that sort of stuff.
You might have a directory of full of ABM files you would pick the one you need,
that's an attachment. That might be a very crude thing that you could do. But
another thing that we didn't do that would be obvious to do here is something that
dynamically gets the keys based on what your messages are.
So, in other words, you don't go and try and fetch these keys, or something that
compromises. Maybe it prefetches the keys at night or maybe it just gets them
on demand, like you get a message and you say I can't decrypt that until I get
these keys. Or maybe it does both. Like some combination of those. But we
didn't try to do any of those kind of experiments like with all of us trying to use
ABM and see what was the most frustrating thing about it or anything like that.
Oh, another thing I'll point out to you is that you have a distinction between what I
would call voluntary and involuntary attributes. So you might have like an
interests database and people could enter interests in it. You could route on that
database. And you can imagine combining that with databases like gender and
the HR database which you view as an involuntary thing so that a kind of
pragmatic thing, like if my group wanted to do it we would be tempted to have
just a voluntary database to do it.
If you wanted to make it effective for kind of CRM enterprise like applications you
would have to have involuntary attributes be available.
>>: Couple times you talked about the possible trade-off between the reading
permissions versus the receiving. I'm wondering if I misunderstood you. If you
made the reading scope larger than the receiving scope and then the message
gets somewhere else, another mechanism. Then someone who shouldn't be
able to read it can, is that ->> Carl Gunter: Absolutely. Let me give that medical example again and explain
it. Suppose you have an organization and the rule in most hospital organizations
is that all the doctors have access to all the patients. The reason being that they
can't tolerate -- the privacy risks, they don't have any cost for, or very little cost
for.
But if a patient had an emergency and the doctor couldn't get their record, they
might get sued. So the decision is that the doctors have to have access to
everything.
On the other hand, if you send a message, then they might do something like
have it forwarded to Gmail, in which case you definitely don't want the thing to go
in Clear Text. So you need to encrypt. But you don't have to encrypt anymore
than the policy that they would get by going to the system and trying to gather the
data directly.
In other words, you don't need the push policy to be a different from the pull
policy. Because if there was a reasonable pull policy, then the push policy
should be okay. So this push policy in this case is the reading policy.
>>: Thanks.
>>: Your value for your attributes, are they assuming a single value for each
attribute, or is there something like a person could have five states?
>> Carl Gunter: You could have -- I'm not sure, you can have enumerated ones.
It can support enumerated ones. It can support boolean's enumerated numerical
ranges.
>>: If you only had half of the states, like you control access by state, you say
this person gets 10 states ->> Carl Gunter: I'm not sure I understand the question there.
>>: If you don't get -- it's kind of a dynamic working question. And it's if you get
a subset of the whole, how did you allow for that where you could say attribute
name with a list of values and it's not a full set.
>> Carl Gunter: Oh, okay. We don't have -- well, we don't have very much by
way of like type checking in the system to verify that you're writing down
something sensible. Like you could write -- you could send messages to empty
sets. You could write down something that couldn't possibly be the case and you
wouldn't even know. So, right, so you might imagine the system -- we did
consider various versions in which the user would get some feedback about the,
what you're actually talking about. Like I wouldn't want to think I have a message
sent to 10 people that's actually being sent to 10,000. So there's some risk
associated here with users misforming the queries and having permission to do it
or forming queries that don't make any sense. Like they have combinations of
attributes that can't occur.
>>: So you have a example, the attributes come before an HR database, which
is controlled by (inaudible). But who can send e-mail to whom is controlled by a
different set of people.
So how do you guarantee that if we're admin we're not intentionally or
unintentionally creating attribute barriers therefore people are changing ->> Carl Gunter: A partial inspiration for this, and this is one of the things we were
interested in, was there would be policies that people could manage. And part of
our inspiration was that the HR department of the University of Illinois has a
mapping like this already. But it's for the pull database, not for the push.
In other words, if you have this HR designation, then you're allowed to get access
to these HR records.
The thought was -- they had a little informal thing saying here's our rules about
like if you're an administrator in the computer science department. You have
access to the HR records of the computer scientists, that kind of thing. Very
much like attribute-based policies. In fact, they are attribute-based policies
already. And they have a list of these things and we got to look at the list.
Our thought was let's try to see if you can encode these kinds of rules. So you
could imagine that the HR people would run this and they would say well here's a
set of pull rules. So those could be push rules. So I don't know if they'd be the
same. It's not impossible for them to manage.
It is fair enough to say this thing of how are you going to manage these rules
seems pretty interesting, but that's like true for any of these attribute-based
systems.
If it's not an explicit list of people who have permission, then it's more -- there's
some challenges with that.
>>: One hopes it's at least better than having maintaining lists.
>> Carl Gunter: Yeah, I think this is the kind of broad agenda I was really hoping
to try to push together today is the next generation of these technologies will
have languages and analysis techniques and algorithms that allow us to avoid
explicit extensional lists and start to incorporate more of the informal
management decisions into the actual software.
>>: Is it more like doing what-if analysis, say I'm picking up what to (inaudible)
deliver it?
>> Carl Gunter: We didn't because we thought, it seemed like the thin end of the
wedge for questions about privacy. So maybe you can have a rule saying
nobody could push to anybody they couldn't pull from. So, in other words, you
would make a risk management decision that they could have gone and found
that in the database themselves. That was part of the inspiration, too for using
the list from the HR guys, saying anything you could have got access to by other
means we'll let you do it for the dynamic mailing list. So, yeah.
>>: Okay. Thank you.
(Applause).
[One hour 20 minutes]