9

Just to say it, the four tenets are:

  • Confidentiality - The message the recipient gets can be proven not to have been read by anyone else since it was encoded.
  • Integrity - The message the recipient gets can be proven not to have been changed since it was encoded.
  • Authenticity - The message the recipient gets can be proven to have been encoded by (edit) a positively-identified sender.
  • Non-repudiation - The sender, given a message received by a recipient, cannot validly deny that the message was sent by him or that it was not the original content sent by him.

This last point seems redundant. If you can prove that the sender sent the message, and separately prove that nobody has changed (or even seen) the message while in transit, then the combination is proven by definition; that the sender and nobody else sent exactly that message and nothing else.

... At least that's my take on it. So, the question is, is there a situation (other than compromise of cryptographic secrets, which indicate a different culpability on the sender's part) in which you can verify the confidentiality and integrity of the message, and the authenticity of the message and its sender, but the sender can still validly repudiate the message?

EDIT: CodesInChaos makes a very good point; you can begin a confidential conversation with a remote party and exchange information, and prove that the information wasn't read or changed, and could only have come from the party with whom you opened the channel. All of this without having a clue who you're talking to.

This kind of undermines the point of "authenticity", though. If something is "authentic" or "genuine", it is what it looks like and/or what its supplier claims it to be. In communications, the very notion of a message being "authentic" implies that its stated source is its actual source. For the message to be "authenticated" as coming from someone, you therefore must know who that someone is in the first place.

Therefore, perhaps a change in definition of "Authenticity" is called for: "The message the recipient gets can be proven to have been encoded by a positively-identified sender". If you cannot identify the sender, you cannot authenticate the message as, in part, having that sender as its source, and therefore of course the purported sender can claim it's fake. This is true even if the message can be proven to be confidential, unchanged, and having come from a definite source location.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
KeithS
  • 6,678
  • 1
  • 22
  • 38
  • You can authenticate to a specific verify in a way that others can't validate (because that specific verifier could have forged the signature). Such an authentication scheme is often preferable over a digital signature. – CodesInChaos May 22 '13 at 17:51
  • 1
    As a side-note, you can see non-repudiation as purely technical putting the blame on a particular key-pair, or as legal where you also need to securely link to a user. The latter is much harder in practice. I guess you're only talking about the technical part. – CodesInChaos May 22 '13 at 17:56
  • Yes, mostly. We are assuming, for the purposes of this question, that no cryptographic secrets are compromised; that is a different problem. – KeithS May 22 '13 at 18:06
  • 1
    Where are you getting these "four tenets" from? I've always heard it as three: "CIA". CIA is not Confidentiality, Integrity, Authenticity. It's Confidentiality, Integrity, ***Availability***. Authenticity & Non-Repudiation would be a sub-set of Integrity, I think. – Iszi May 22 '13 at 20:13
  • @Iszi - Availability is a fifth tenet, separate from all others mentioned. The CIA model typically relates to storage of information; keep unauthorized people from getting it, protect the correctness of it, and keep it available to authorized people. Two additional tenets shake out when it comes time to communicate it; make sure the party with whom you're communicating is who they say they are and that what you "heard" is what they "said", and make sure neither side can deny the communication occurred. – KeithS May 22 '13 at 20:27
  • 1
    @KeithS http://en.wikipedia.org/wiki/Information_security#Key_concepts – AbsoluteƵERØ May 22 '13 at 21:52
  • 1
    @KeithS - Even back in the Orange Book days, CIA was always Confidentiality, Integrity and Availability. Authenticity, Non-repudiation and others are extras on topic of the generally accepted industry model. – Rory Alsop May 24 '13 at 09:55
  • Is non-repudiation even a tenet? I know there are systems where it's considered desirable that any party to a conversation can pretend to have received messages from any other party. – user253751 May 20 '22 at 09:12

3 Answers3

8

One simple protocol that can be verified by a certain target user but not by third party:

  1. Use a Diffie-Hellman key exchange on your key and the receivers key
  2. Use the shared key to encrypt a message and add a MAC

This protocol offers the first three properties, but not the fourth. So the answer is NO.

Everybody who knows the shared secret can forge the MAC. But since by default only the sender and the recipient know it, the message is still authenticated as coming from that sender as far as the legitimate reception is concerned.

But the reception can't prove who sent the message, so the scheme doesn't provide non-repudiation.

A popular protocol that is signs its data, providing (technical) non-repudiation are GPG encrypted emails, a popular protocol that only uses MACs for the user data is TLS. Some protocols like OTR go out of their way to increase deniability as much as possible(e.g. by leaking obsolete MAC keys) while still providing the first three properties to the two legitimate users.

Bruno Rohée
  • 5,221
  • 28
  • 39
CodesInChaos
  • 11,854
  • 2
  • 40
  • 50
  • ... yes, but on its face this is no different than if I chose to trust a self-signed certificate when initiating a TLS handshake. Just because only you and I know a key and can thus communicate *confidentially* and with *integrity*, doesn't mean I actually know who you are and can thus verify that the messages I am getting are coming from whom I expect them to. I would say this does not provide *authentication*, because verifying a message as genuine, authenticating it, involves positive identification of the sender as the party who *should* be sending the message in the first place. – KeithS May 22 '13 at 18:45
  • @KeithS The difference isn't about how you choose which public key you want to communicate with/trust. That is an orthogonal concern. It's about how how the key is used. With GPG the message is signed, with TLS a symmetric key is exchanged and used to MAC the actual message. A MAC can't prove to third parties who wrote something, a digital signature can. – CodesInChaos May 22 '13 at 18:50
  • Right, but TLS allows for remote party authentication during the handshake, via certificate exchange, independently from the use of the exchanged key. Authenticating the *sender* as not only being the party you began the conversation with, but the party you *wanted* to begin the conversation with, is key to authenticating the *messages* exchanged as genuine. It would thus follow that the D-H scheme which I was referring to doesn't actually provide authentication, and thus it cannot provide non-rep. Perhaps that requires a change in definition of "authenticity" from my OP. – KeithS May 22 '13 at 19:14
  • @KeithS I don't understand what you want to say. I assume that the public keys of both sides are known. The key distribution problem is the same no matter which crypto you use. Once you know the keys, you can either compute a shared key with DH and MAC the message. This proves to the recipient who sent the message, but the recipient can't prove it to anybody else. Nobody can forge the sender of such a DH + MAC message unless either the legitimate sender or the legitimate recipient leak some key. – CodesInChaos May 22 '13 at 19:26
  • I have edited the OP. The problem is in defining "authentic" as somehow not requiring the identification of the real-world sender. I can initiate an asymmetrically-secured key exchange, whether based on the RSA scheme or D-H, with any IP address on the Internet that understands the request I am making. I can assert that the resulting communication channel is confidential, and if a MAC-based encryption mode is used, that the messages exchanged are unaltered. The messages are still garbage because I don't know and can't prove who sent them, and thus I can't assert the messages to be "authentic". – KeithS May 22 '13 at 19:56
  • @KeithS Linking an asymmetric long-term keypair to a a real person is a hard problem, yes. But there is no difference between DH and digital signatures in that regard. You always need some way to figure out which public key belongs to the sender. I assume that everybody knows that key `A` belongs to Alice and key B belongs to Bob. In that situation if Alice sends a message to Bob and signs it, Bob can prove to everybody which message Alice sent him. With DH Bob still knows the message came from Alice, but he can't prove it to anybody else. – CodesInChaos May 22 '13 at 20:09
  • How? How would Bob know that a message came from Alice when using D-H? The scheme doesn't verify either party's identity; anyone can generate a random key component, and use it along with the other party's modulated key base to set up a shared key. The Wikipedia page specifically calls it an *anonymous, non-authenticated* key agreement protocol. That's my point; you must authenticate the sender to authenticate any messages from a sender, and if you don't you cannot have non-repudiation. – KeithS May 22 '13 at 20:20
  • @KeithS When you compute the shared secret of Alice's and Bob's long-term key then neither side can choose that shared secret. Knowledge of this secret proves that you either know the private key of one of the two legitimate users, or one of them leaked the shared key to you. Since Bob knows that he didn't write the message himself, the only other possibility is that Alice wrote it. ANON_DH in TLS is unauthenticated, because both sides use an ephemeral key. But nothing prevents you from having a long term DH key and using it for authenticating via MAC. It is my favourite form of authentication – CodesInChaos May 22 '13 at 20:23
  • But, how does Bob know he's talking to Alice in the first place? He may know that the other party to his conversation wrote the message (because he didn't and no-one else could have), but he doesn't know who that other party is. MACs are for message integrity verification; proof the message is exactly what the other party sent (and did actually come from the other party), but there's no identity validation inherent in it. Maybe you're suggesting using SPEKE (password-based DH variant)? – KeithS May 22 '13 at 20:45
  • @KeithS But, how does Bob know that Alice signed a message? Because Alice's key was used, Bob assumes it was Alice who signed it. Same for DH. If the other party used Alice's long term key for the key exchange then Bob assumes it was Alice that sent it. If Alice does a key-exchange with her long-term public key with a key Bob as exclusive ownership of, and then computes a MAC using the shared key, she proved(to Bob) that she knows the shared key and thus is the only party apart from himself who could have written that message. – CodesInChaos May 22 '13 at 20:56
  • I still don't understand; what's Alice's "long-term key" in DH terms? Is it her secret, *a*, or the generator *g* or prime modulus *p*, or something used to generate one or more of them, like a shared password? For Bob to know it's Alice, Bob would have to know something that, in the simple ephemeral DH scheme, only Alice would know. – KeithS May 22 '13 at 21:27
  • I am, however, starting to understand that there are ways to use DH to verify the other person is who they say they are but not be able to prove it to anyone else after the fact, which is a practical requirement of non-repudiation in the legal sense. SPEKE's one possibility; even giving up the password used in key exchange isn't a proof for posterity that any given message was sent by Alice. – KeithS May 22 '13 at 21:28
4

Search this site on non-repudiation. You'll find lots of information about the topic. In particular, you'll discover that non-repudiation is not a technical property (contrary to what cryptographers might tell you); it is primarily a socio-legal property. Thus, non-repudiation cannot be assured through technical means alone: it can only be achieved through a combination of technical, social, and legal mechanisms.

Consequently, confidentiality, integrity, and availability are not enough to ensure non-repudiation.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 3
    Add to that: Non-repudiation doesn't exist (you can assert that your private key has been compromised, thus repudiating the signature). Non-repudiation isn't desirable (what if your private key really IS compromised?) If a transaction *really **wasn't** by you* then you ***need*** to be able to repudiate it. – Ben May 24 '13 at 13:39
0

Consider CIA, IAA model.

  • Confidentiality: Keep secret from those not authorized
  • Integrity: Prevent unauthorized tampering
  • Availability: Ensure authorized parties can access the data

CIA is all about allowing actions which are authorized, and preventing actions which are not. So what actions are authorized? That's IAA:

  • Identification: Who I claim to be (e.g. username, digital cert),
  • Authentication: How I prove it (password, signature),
  • Authorization: What is that person allowed to do e.g. role-based security.

Clearly you cannot authorize an action without first identifying, and authenticating, the person who is doing it.

Imagine placing an order. Non-repudiation requires:

  • identification (who placed the order/who did they say they were),
  • authentication (prove it was them that placed it),
  • authorisation (were they permitted to place it? Or should they have read-only access?),
  • integrity (prevent the order records being tampered with or faked) and
  • availability (ensure the order record is available to the people fulfilling it.)

Generally speaking non-repudiation is an anti-feature. Rather than trying to provide that, provide repudiation - reject orders you cannot show are probably valid, and ensure you have enough audit trail to investigate disputed orders - so that's accurate times, web logs, IP addresses, and so forth. If the IP address is in China, but they were not, chances are they didn't place the order: You should have flagged that up at the authentication step so you will have to eat the cost.

Ben
  • 3,697
  • 1
  • 18
  • 24