In cryptography, a trusted third party (TTP) is an entity which facilitates interactions between two parties who both trust the third party; the third party reviews all critical transaction communications between the parties, based on the ease of creating fraudulent digital content. In TTP models, the relying parties use this trust to secure their own interactions. TTPs are common in any number of commercial transactions and in cryptographic digital transactions as well as cryptographic protocols, for example, a certificate authority (CA) would issue a digital certificate to one of the two parties in the next example. The CA then becomes the TTP to that certificate's issuance. Likewise transactions that need a third party recordation would also need a third-party repository service of some kind.
'Trusted' means that a system needs to be trusted to act in your interests, but it has the option (either at will or involuntarily) to act against your interests. 'Trusted' also means that there is no way to verify if that system is operating in your interests, hence the need to trust it. Corollary: if a system can be verified to operate in your interests, it would not need your trust. And if it can be shown to operate against your interests one would not use it.
YouTube Encyclopedic
-
1/3Views:5 4961 427242 795
-
Trusted Third Party - Applied Cryptography
-
Trusted Third Party Solution - Applied Cryptography
-
Why digital certificate?
Transcription
I'm going to discuss one other non-solution. We'll call this one #0B, which is to use a trusted third party. Here is the idea, that we have some very, very trustworthy place, and we'll make it green. People trust things that are green. We have this very trusty place called TrustyKeys, and TrustyKeys has a shared secret with each individual in the network. Now if Alice and Bob want to communicate, the protocol is Alice sends a message to TrustyKeys that says she wants to communicate with Bob. That's step 1 of the protocol. What TrustyKeys will do is generate some new key, some new secret key, and we'll call that KAB because it's for Alice to communicate with Bob. In step 3, TrustyKeys will send the new key to both Alice and Bob, and it will send it encrypted using the key that's already shared between those 2 parties. What it sends to Bob is the encryption using KB, the shared key between Bob and TrustyKeys of something that says Alice's name concatenated with the actual key. And what gets sent to Alice is encrypted with KA, the shared key between Alice and TrustyKeys and the name Bob along with KAB. At this point, both Alice and Bob know KAB and can communicate securely using KAB to encrypt messages between them. The quiz, to see if you understand third party key distribution, what could go wrong with this protocol? The choices are TrustyKeys can read all the messages that happen between A and B over their encrypted channel. TrustyKeys can impersonate any customer that shares the key with TrustyKeys, and some evil party C could tamper with messages in step 3 to steal the key AB and set up a different key between Alice and Bob and then steal their traffic.
An example
Suppose Alice and Bob wish to communicate securely – they may choose to use cryptography. Without ever having met Bob, Alice may need to obtain a key to use to encrypt messages to him. In this case, a TTP is a third party who may have previously seen Bob (in person), or is otherwise willing to vouch for that this key (typically in a public key certificate) belongs to the person indicated in that certificate, in this case, Bob. Let's call this third person Trent. Trent gives Bob's key to Alice, who then uses it to send secure messages to Bob. Alice can trust this key to be Bob's if she trusts Trent. In such discussions, it is simply assumed that she has valid reasons to do so (of course there is the issue of Alice and Bob being able to properly identify Trent as Trent and not someone impersonating Trent).
Actual practice
How to arrange for (trustable) third parties of this type is an unsolved problem.[1] So long as there are motives of greed, politics, revenge, etc., those who perform (or supervise) work done by such an entity will provide potential loopholes through which the necessary trust may leak. The problem, perhaps an unsolvable one, is ancient and notorious. That large impersonal corporations make promises of accuracy in their attestations of the correctness of a claimed public-key-to-user correspondence (e.g., by a certificate authority as a part of a public key infrastructure) changes little. As in many environments, the strength of trust is as weak as its weakest link. When the infrastructure of a trusted CA is breached the whole chain of trust is broken. The 2011 incident at CA DigiNotar broke the trust of the Dutch government's PKI, and is a textbook example of the weaknesses of the system and the effects of it.[2] As Bruce Schneier has pointed out, after the 2013 mass surveillance disclosures, no third party should in fact ever be trusted.
The PGP cryptosystem includes a variant of the TTP in the form of the web of trust. PGP users digitally sign each other's certificates and are instructed to do so only if they are confident the person and the public key belong together. A key signing party is one way of combining a get-together with some certificate signing. Nonetheless, doubt and caution remain sensible as nothing prevents some users from being careless in signing others' certificates.
Trusting humans, or their organizational creations, can be risky. For example, in financial matters, bonding companies[clarification needed] have yet to find a way to avoid losses in the real world.[clarification needed][citation needed]
Parallels outside cryptography
Outside cryptography, the law in many places makes provision for trusted third parties upon whose claims one may rely. For instance, a notary public acts as a trusted third party for authenticating or acknowledging signatures on documents. A TTP's role in cryptography is much the same, at least in principle. A certificate authority partially fills such a notary function, attesting to the identity of a key's owner, but not to whether the party was mentally aware or was apparently free from duress (nor does the certificate authority attest to the date of the signature).
See also
References
- ^ Zissis, Dimitris; Lekkas, Dimitrios; Koutsabasis, Panayiotis (2012). "Cryptographic Dysfunctionality-A Survey on User Perceptions of Digital Certificates". Georgiadis C.K., Jahankhani H., Pimenidis E., Bashroush R., Al-Nemrat A. (Eds) Global Security, Safety and Sustainability & E-Democracy. E-Democracy 2011, ICGS3 2011. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, Springer, Berlin, Heidelberg. 19.
- ^ Guardian: Rogue web certificate could have been used to attack Iran dissidents, visited 11 September 2011
This page was last edited on 7 January 2024, at 17:24