Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
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
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
1  
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 9:55

3 Answers 3

up vote 7 down vote accepted

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

  1. Use a Diffe-Hellman keyexchange 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.

share|improve this answer
    
... 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

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.

share|improve this answer
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

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.