Access Control is powerful. System-central storage is a bit
iffy. How do we stop people from abusive tapping?
Access Control is powerful. System-central storage is a bit iffy. How do we stop people from abusive tapping?
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
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.
Do not just read the empty words below; do try them, playing
a2rule and checking your suspicions. The quick
feedback will be instructive. When you stick to
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 firstname.lastname@example.org remote email@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 firstname.lastname@example.org remote email@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 firstname.lastname@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@email@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 firstname.lastname@example.org 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.
In the examples above, we simply pressed Enter when prompted with
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 email@example.com 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!
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_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_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
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.