Sep 9
Jim's notes ...
read six papers
now tagged blue in
Google drive / Identity Auth / Trust Papers / Read / ...
InfoTheoreticTrus.pdf most interesting
Talked about an idea for a "formal" system
of trust, asking questions about how some
subset a (conspiracy + dupe) could affect
the rest of the network.
Sam's notes -
Firstly, with the papers, some good stuff and some not so good stuff (in my opinion) talking about different ways to formalize and/or quantify trust in distributed networks (especially re: identity authentication). Generally I have philisophical issues with trying to reduce "trust" to a specific quantity, other than in cases with a singular action with perfect information and a consistent risk, where the trust can be viewed as the simple average of how often the trustee has fufilled their trust on previous occasions. The InfoTheoreticTrust paper, for instance, nicely extended this (in the case of packet forwarding) with some information-theoretic uncertainty mechanisms to add an additional component. I do think it's possible to well-order trust in nodes in a system, and if you want to do this by putting an arbitrary value on it, then bully for you, however all the papers I've read that attempt to do this get bogged down in justifying their value, which I have yet (and don't think I reasonably could) be convinced could be sufficently well-defined as to semantically meaningful in and of itself. I think all these attempts are houses of cards, and since they are ultimately arbitrary they are exploitable, were one to build a real world system on the backs of them.
My formal system proposal is not evaluating "trust" as a measure, but rather trying to spot weaknesses within identity authentication protocols which do not consider the broader network of trust relationships inherent in the ability of the actors in the system to properly execute it. Essentially, the idea is that on a top level you have a protocol like this:
1. A trusted authority TA confirms Bob's identity. They then issue Bob a private key, and post a certificate asserting Bob's identity and containing the corresponding public key and the TA's cryptographic signature.
2. Alice takes the certificate, and verifies the TA's signature. She then encrypts a message with Bob's public key and sends it to Bob, confident only Bob can access it.
3. Bob recieves Alice's message.
You have trust relationships like that between Alice and the TA. At the top level, each is responsible for making sure actions taken in their name are correct. However, we can break them down into telescoping levels of active parts (Alice -> Browser -> CryptoLibrary -> Compiler -> OS -> CPU -> Motherboad, etc., TA -> CA -> RA -> Manager -> Dev -> Software -> Hardware, etc.), and then look at what subgroups of entities can correctly authenticate without the high level actor being the wiser. These connections could also be described as a three-tuple of binary values for (Explicitness of Trust (vs. Implicit), Persistence of Trust (vs. Per Use), Generality of Trust (vs. Action Specific)), which could assist with describing it.
All pretty vague, but the idea is starting to take shape.
