Access 5: Juggling Keys in the Rules DB

Access Control is powerful. System-central storage is a bit iffy. How do we stop people from abusive tapping?

This article is part of a series on access control and is related to another series on identity.

The worst thing that can happen to a service hosting provider is if their databases are tapped, and the information of many users is published to people of debious repute. The ARPA2 Rules DB is designed to not be an interesting catch for such people.

Cryptographers are funny people. Given a pile of useful information, we turn it into unreadable gibberish. And we pride ourselves on the fact that you will not recognise back your original information. Plus, when presented with the same information, we guarantee delivering the same gibberish... well, that might actually be useful!

Hierarchy of Keys

As explained in Dialing into Access Control, the access of a database gradually approaches the targeted field. We use the Access Domain and an optional Database Secret as a first level, much like a country code in telephony. Then comes an Access Type like comm or docu or group, which compares to an area code. Finally, the (Remote) Selector and a resource-description string called the Access Name finds is like the actual phone that we want to ring.

Keys are derived at each of these levels. They are called the Domain Key, Service Key and Selector Key. And they all look like long hexadecimal sequence, devoid of content for anyone but the odd folk known as cryptographers.

We introduced the a2rule utility and innovated it heavily since then (yes, in just two days). We added the desirable support for Document Access, a generic Ruleset Access interface.

Do not just read the empty words below; do try them, playing around with a2rule and checking your suspicions. The quick feedback will be instructive. When you stick to get actions you should not cause any damage while playing around.

Rule DB and Password

An addition that we first made for debugging, but realised as incredibly potent for users, was the dumping of the keys at various levels,

shell# a2rule comm get local john@example.org remote mary@example.com
Domain Key not in $ARPA2_DOMAINKEY_example_org
Database Secret: 
Trunk number: 0
Domain   Key: f6559b947113d42b0a6ae4542a4f8c8e77178a1935858f6d2b8e1a712899c35e
Service  Key: 3ced5fc5b2aaa1c45acc71230f267886cb97fdc9ac95505b6e0373e221eac665
Selector Key: 165426bc7ba66c93e2872d9fcc1c6060954c70605a5d99686687af09c64faaf0
DBrule: #a2xs %W

What you can see here, are the three levels of keys from the "dial plan" just described. If we change the Access Name or Remote Selector we should get another Selector Key, and indeed:

shell# a2rule comm get local john@example.org remote sweetsister@example.com
Domain Key not in $ARPA2_DOMAINKEY_example_org
Database Secret: 
Trunk number: 0
Domain   Key: f6559b947113d42b0a6ae4542a4f8c8e77178a1935858f6d2b8e1a712899c35e
Service  Key: 3ced5fc5b2aaa1c45acc71230f267886cb97fdc9ac95505b6e0373e221eac665
Selector Key: 2da13bd48746e6450b56f0c8abb4211aae29a8f61d28356ba51bfa289e2e97d7
No rules found in the database

The Domain Key and Service Key do not care for the Remote Selector, but the Selector Key does, so that hex code is different. Unrecognisably different, and flipped an average of half the bits, a cryptographer would proudly add. Also note that no rule was found this time, due to the changed Selector Key.

So let's change the Service Key and see that the Selector Key changes along with it, but not the Domain Key:

shell# a2rule group get member cooks+vegan@example.org        
Domain Key not in $ARPA2_DOMAINKEY_example_org
Database Secret: 
Trunk number: 0
Domain   Key: f6559b947113d42b0a6ae4542a4f8c8e77178a1935858f6d2b8e1a712899c35e
Service  Key: f9bbc0890a3328855ea9a7cf2e0dd75d67a958db547bae75c1833a23b8e1b13b
Selector Key: 817823302bfd2cce699636108317601e00f44e9ec4c15fb86f93b3f305829ef9
DBrule: #a2xs %RWA ^vegan@john@example.com

This does indeed change the Service Key and logically also the Selector Key; and although it finds a DBrule it is a different one. But as expected it does not alter the Domain Key. For that, we really not change the local domain:

shell# a2rule group get member cooks+vegan@example.net
Domain Key not in $ARPA2_DOMAINKEY_example_net
Database Secret: 
Trunk number: 0
Domain   Key: 83b448a3e4d0e14088a92f2fbc2f0cda69e11829b16282ba574bd64972f18b13
Service  Key: 861c9784f465912689bc8dabbda83b8965bf9d29e1434b33f17bf27d891992a5
Selector Key: 551056495b2ee675fdbe49e1b1850e4cc67ebd9071addb9e87c081d5d10e1f0a
No rules found in the database

As might be expected, all three Keys change as the result of a different domain name, and any DBrule should be located in the changed location of the Selector Key. Generally, this is the idea, that changes at any of the levels perturb the process of database lookups, or relocate it to other codes. The codes are too large to guess, of course. It's one of those things that cryptographers pride themselves for.

Database Secrets

In the examples above, we simply pressed Enter when prompted with Database Secret:, which is the good-old password prompt from getpass(). If you entered an actual string you would hit a fourth level of perturbation:

shell# a2rule group get member cooks+vegan@example.net
Domain Key not in $ARPA2_DOMAINKEY_example_net
Database Secret: 
Trunk number: 0
Domain   Key: ceff8176af41a983433086210ab54db33971f02220d68675f4e3dd7adef7782a
Service  Key: d61d4d67acb92bf1f003a63288cf30cc9cb5052fa0b1196dd9dda7591f1f2d52
Selector Key: 24d7924681f27797c5ede91152d0dbec0bff8d1278db24b10b6b0dbc6a5b0eb5
No rules found in the database

That's for typing a mere x after the prompt. As if you planted your Tree of Keys in completely different soil. And that's the idea; you can have as many trees as you like, as long as you protect them each with their own password.

Now, passwords are a nuisance; they may add a useful daytime regime to the life of a system administrator, but not "normal" users. So now let's divert the password prompt!

Lower Secrets

The top-level entry to Access Control will always be protected by a password, but the lower-level keys can be spread more easily to administrators who control only a portion of the tree.

The Domain Key may be handed over to the owner of a domain, or their administrator. As you can see in the dumps above, an environment variable is tried to load it. When this is found, it effectively bypasses the Database Secret prompt, because en entrance point lower in the key tree is available. Note how a mangled domain name is part of the variable name, so you can have variables for each domain if you own many.
The Service Key is usually handed over to a service provider. Given a hosted service, the domain name and Access Type ought to be fixated, and crossing over to other domains and/or types is not a good idea without explicitly providing them with the corresponding Service Key material. That's how cryptographers can actually be a bit useful, by assuring that to be safe. We are experimenting with an environment variable for this too, but have to see if it works out in practice.
The Selector Key is derived through iteration, usually as part of a database access process. For instance, the calls access_comm() and access_document() can be handed a Service Key, and they may iterate from concrete to abstract on a Remote Selector to derive the various Selector Keys locally.

And yes, users matter:

Perhaps User Keys would make sense too, if a domain has users that may control aspects of hosting. In fact, the code used for derivation is a sequence of rules_dbkey_domain(), rules_dbkey_service() and rules_dbkey_selector() and the first takes in something called a domain, but not really checked to be just a fully qualified domain name; we may formalise support for a user@ prefix but already have "accidental" support for this useful idea.

Juggling Keys is What We Do

In the end, souvereign use of the Internet involves handling privacy and securty, and that always ends up as a game of juggling keys. The scheme presented here is designed to gradually dissiminate control, following the path considered the authoritative scheme behind systems such as DNS and URL notations.

Most of the time, you should not notice these games. You simply have the key you are supposed to know, and can do your work, running a2rule and never entering any password. The only exceptions are when you control the tree of rights from the top, handing out datbase keys to those below your realm of control.

Go Top