-
Notifications
You must be signed in to change notification settings - Fork 2
Home
This library provides a public key infrastructure (PKI). It is based on ASAP, a routing protocol specialized decentralized networks, especially ad-hoc networks.
The concept is very close to PGP but easier to integrate into an ASAP environment. The library allows
- creating RSA keys
- create certificates
- exchange certificate in a pure decentralized system
- calculate a probability of correctness of a certificate
There is a 32' video explaining the concept of that component.
The very core of each certificate is a public key of a user, lets say A(lice). A public key can be used by others to a) encrypt data to be sent to the user and b) to verify a digital signature.
A PKI is as save as the relation between a real person and its public available key can be guaranteed.
Attackers try to impersonate others. An attacker, lets call him Mallory, would another person (e.g. Bob) that he is actually Alice. Each good PKI should give Bob enough time and the means to verify issuers claim. That's not an issue of computer science - it is about real world.
Receivers of a public key must ensure that this key belongs to the person (technical term: subject). Mallory will always try to trick others. He is to blame. But receivers are even more to blame if they neglect to perform a reasonable checking. Bob should look at Mallory, ask for an ID or something like that and realize that he is not Alice.
Receivers can create a certificate if they are convinced of subjects' identity. Alice met Bob for instance. Bob is convinced that he really met Alice. He would take the public key, add the name Alice (and a view other parameters) and sign it. Bob becomes issuer of a certificate.
A certificate is a proclamation of the issuer:
I, the issuer (Bob), herewith proclaim, that this public key belongs to the subject (Alice). I sign it.
A certificate contains at least: Subject (name, id or both), issuer (name, id or both), subjects' public key. There is usually a valid since and until timestamp. Lets use the abbreviation: cert(B,A) - B signed A.
Even Alice would be interested in getting this certificate. Why is that? She could present this certificate others, e.g. C(lara). Clara would try to verify the signature.
She can do so if she has got issuers' public key. Clara could verify that Bob proclaimed that the public key belongs to Alice. Clara could use this key, if she trusts Bob. We are going to discuss this special kind of trust very soon.
The previous considerations are the basics of digital certificates. This library adds a view concepts. But before that; here are some general settings:
- Key pairs are automatically removed after one year. They an be refreshed earlier but they will no longer exists. Users have to meet again exchange their new keys.
Signing a public key is a very critical moment in each PKI. An issuer must ensure that s/he is not fouled by an attacker. There is always a probability to sign the wrong subject, though.
We use the term signing failure for this probability. Probabilities range from 0% (never happens) to 100% (always happens). We shorten the numbers and use integer values from 0 (= 0% never makes any mistake) to 10 (= 100% is always cheated).
Each person in our PKI can define a signing failure for any other person. This number is never published. The signing failure describes e.g. Alice' estimate how easy Bob can be cheated. Most likely, estimations of Alice and Clara will differ.
Signing failure is not a measure of how persons like each other. Alice and Bob could be very close friends. Nevertheless, Alice could estimate that Bob is somewhat sloppy in this matter. Maybe, it is part of his charming nature. It makes his certificates not better, though. Maybe, Clara does not like Alice at all but has to admit that she is very thorough in this matter.
The signing failure estimation is not a measure of friendship but of thoroughness.
Lets use this abbreviation: sf(B,5) - signing failure of B is estimated 5 (== 50%)
In this lib we define:
- sf(yourself, 0). We never make mistakes.
- sf(!yourself, 1 <= x <= 10) Signing failure of any other person than ourself can never be better than 1.
The reason is explained very soon.
Public keys are used to sign (and to encrypt) data. A certificate is one example.
By verifying a signature, we verify its sender. But how sure can we be? In other words: What is the probability that we are cheated?
Bob directly received a public key from Alice. In this library, he has to assume to make no mistakes. Bob can be sure of Alice' authorship if he can verify the signature.
Clara received Alice' public key with Bobs' certificate. Lets say, Clara estimates Bobs' signing failure to 5 (= 50%). Half of Bobs' certificates are false. They contain a public key. But this key does not belong to the subject. Bob was cheated about subjects' identity during key exchange.
Clara has got a message. It is signed by Alice. Clara got Alice public key from Bob. Ironically, the situation is very clear if she cannot verify the signature. This message is most probably not from Alice.
It becomes more complex, if Clara can verify the signature. She can calculate: Due to here estimation of Bobs' signing failure, the chance to work with a wrong public key is 50%.
What is the probability that this message is from Alice after a successful verification? 50% of course. Only half of Bobs' certificates are false. The other half is ok.
Identity Assurance is a probability. How sure can we be of senders' identity after a successful verification? It is a product.
A more complex example. Assume:
- There are Alice, Bob, Clara and David
- We have estimated their signing failure: sf(A, 1), sf(B,5), sf(C,2), sf(D,3).
- We only met Alice directly. We have got some certificates: cert(A,B), cert(B,C), cert(C,D). Alice signed Bob, Bob signed Clara etc.
- We received a signed message from David. We can verify this message.
Question: How sure can we be of Davids' identity?
We have its public key. But we have not met him in person. We have a certificate issued by Clara, though. We assume that Clara is quite thorough but 20% of her certificates are wrong.
In other words: There is a 80% chance that we have got the right public key.
Unfortunately, we cannot verify this certificate directly. We never met Clara in person. We have a certificate issued by Bob, though. We think of Bob very highly but is is often distracted. We assume 50% of his certificates are wrong.
In other words: There is a 50% chance that we have got the right public key of Clara. We assumed that we have an 80% chance that Clara signed Davids' certificate correctly. We have a 0,5 * 0,8 = 0,4 = 40% chance that we have got the right public key of David.
Unfortunately, we have not met Bob in person. We have a certificate issued by Alice. We assigned her the highest signature failure possible (1 == 10%).
In other words: there is a 90% chance that we have got the right public key of Bob. Lets calculate: 0,9 * 0,4 = 0,36 = 36%. We have a 36% chance so far that we have got Davids' right public key. Fortunately, we met Alice directly. We make no mistakes. Identity assurance is not getting worse. Let's calculate: 1 * 0,36 = 0,36 = 36%.
Answer: Our identity assurance of David is 36% = 4 in our example.
Lets assume we don't have a public key of Bob. Maybe we have no certificate from Alice (cert(A,B)) or this certificate is outdated. What now? We have a signed message. We have got the required public key. It is signed by Clara. Her key is signed by Bob. We cannot verify Bob. But hey, there are so many persons involved. This must count for something.
No, it does not. It is not about social relations. It is a simple calculation. We cannot verify Bobs' certificate. We have no idea if there even is a real person behind this public key. The whole Bob, Clara, David chain can be a ploy.
If you know those people, meet them and exchange keys.
Identity assurance is 0 if we have not got a public key directly and if their is no unbroken chain of certificates that leads to the sender.
How can we improve identity assurance.
We could set the signature failure of each person to its minimum (1 = 10%) which is not a very good idea. But it illustrates an effect.
- 0 hops: Identity assurance is 10 if we met the person directly.
- 1 hop: We met a person A who met person B. Identity assurance of B would be 90% = 9 on our side.
- 2 hops: 0,9 * 0,9 = 0,81 = 81% = 8
- 3 hops: 0,9 * 0,9 * 0,9 = 0,729 = 73% = 7
- ...
The numerical sequence is obvious: 10,9,8,7,6 etc. We defined the best signing failure to be 1 to get that effect. A minimum failure of 0 would keep users in a mistaken feeling of pure safety (10, 10, 10, ...).
There is no such thing as perfect security. That's a fact but no reason to be afraid. We have to be aware of it and work with it. Each intermediary step makes assurance weaker. That's true in the real world as well as in the digital one.
Be honest with yourself when estimating signing failure. A better number does not increase security. It clouds your justment. Don't be afraid of uncertainty. Deal with it, embrace it. We can only work with things we realize not with things we hide from ourselves.
A low identity assurance of someone can also be read as sign to met this person. In most cases, talking to people is a good thing. There is only way to a better identity assurance: Shorten the chain. Exchange keys with as much persons as you can.