Homomorphic encryption and authorization

Homomorphic encryption and authorization

While submitting topics to a professional group for a presentation, I came across homomorphic encryption and was idly playing with the idea.  And suddenly realized that there is a use for pretty much any form of it, which we tend to need these days.

We have, of course, been using homomorphic encryption for years, even though it has been recently rediscovered anew.  Homomorphic encryption is simply the encryption of content, and then the use of it for various functions while still encrypted.  If you choose the right algorithm for the encryption, you can perform certain functions on the encrypted material and get valid results without ever decrypting the information, and therefore exposing it to disclosure.

As I say, although recent research has developed new algorithms which allow us to add, multiply, and perform other specific functions with homomorphic encryption and encrypted data, we have been using it for years.  The way that we have been using it is the way that we store and verify passwords.  We do not store the plain text of the password.  We store a version of the password that has been one-way encrypted by means of some kind of hash function.  Storing the hashed version of the password means that the original password cannot be discovered or disclosed.  We never decrypt the original password because we can't.  (Yes, yes, I know all about rainbow tables.)  (As a matter of fact, we'll be talking about rainbow tables in a minute.)  We simply compare the encrypted hash of the password that has been entered with the encrypted hash of the password that we stored.

And I remember a situation which is quite common.  We want to grant access to a number of our employees.  Possibly all of our employees.  Possibly all of our employees and a few contractors as well.  We do not want to issue them all usernames and passwords and to authorize those particular identities for access.  That would involve an awful lot of administration.

This is a common situation and is typically seen where a building is secured and the main entrance is guarded in some form, with verification of the access rights of those who are entering.  Very often we have a loading bay at the back of the building.  The loading bay is very often used as a sort of unofficial employees' entrance.  Of course, we have to provide access to any vendors and delivery drivers who are making deliveries to our loading bay.  So we give everybody a PIN to unlock the door of the loading bay.

But this creates a problem.  We have given everybody the same PIN.  We have an awful lot of employees, and we have a bunch of contractors and delivery people and vendors who also need access.  Everybody gets the same PIN.  Not everybody takes the same care of it.

So we have a situation where we start to realize that unauthorized people have been given the PIN and are misusing the access.  Now, we could issue everybody with an individual PIN.  However, we've only got 10,000 possibilities, and if we have a thousand employees and vendors and contractors who need PINs, then that means that our address space is going to be pretty close to exhausted.  Somebody is probably only going to have to try ten PINs in a row to hit one that will in fact work.  Or we could just change the PIN once a month, and then tell everybody, absolutely everybody, what the new PIN is.  That will possibly limit the misuse for the first part of the month, but it's another big administrative task on an ongoing basis.

So we issue everybody a different password.  But the thing is, they all hash to the same PIN.  (Getting a set of passwords of this nature is where the rainbow tables come in.)  Putting an alphanumeric keyboard in place, and a little bit of hashing circuitry, we can use pretty standard security hardware for all of this.

(I mean, we could, if we wanted to, just simply use the alphanumeric conversion that allows people to remember phone numbers more easily.  No, it's not a terribly good idea in security terms: it's too easy to figure out what's going on.)  (And in case you think that I don't need to warn people about that because nobody would be stupid enough to ever use it that way, I do have personal experience of a chartered bank who actually did this in order to make their online banking compatible with their telephone banking.  Once I figured out what they were doing, I used all kinds of variations on my password, and they all worked.  I never used my actual password again for logging on to their online banking.)

At this point, everybody's got the same access code, but none of them know it.  Everybody's got a different password.  They use the password, and they get access.  If we start to notice misuse, all we have to do is look at the actual password that is being typed in and figure out who is giving away their password.  We've covered the authorization part, in terms of access to the building, and now we have some accountability, in terms of who is being cavalier with password security.