12

I want to ensure the sender of Document B is the same person as who previously sent me Document A. Both documents are signed with self-signed certificates. I'm not interested in knowing the real-world identity of the sender.

When I open the self-signed certificate with a certificate viewer, it shows the certificate's subject, issuer, serial number, subject key identifier, public key (very long gibberish), SHA1 digest of public key, X.509 data, SHA1 digest (of what?), and MD5 digest (of what?).

I know the issuer of the self-signed certificate can put arbitrary things into (i.e., fake) "subject," "issuer," "serial number" fields, so they are meaningless. But I don't know anything about other fields.

If the certificates contained in those two documents have, for example, exactly same "SHA1 digest of public key" string, does that mean they are indeed signed by the same person? Can an attacker fake it?

certnoob
  • 123
  • 5
  • 1
    Possible duplicate of [Basic self-signed certificate questions](https://security.stackexchange.com/questions/44340/basic-self-signed-certificate-questions) – Tom K. Jan 16 '18 at 15:02
  • I'm going to argue non-dupe. That one is about self-signed CA certs, this one is about document signing certs. – Mike Ounsworth Jan 17 '18 at 03:27

4 Answers4

22

Public and private keys are linked in such as way that if two certificates have the same public key, they were created using the same private key.

So if you assume that the private key is indeed kept private, the part you can trust in the certificates to identify the creator is the public key, and by extension the digest of the public key.

Sjoerd
  • 28,897
  • 12
  • 76
  • 102
  • 6
    `if you assume that the private key is indeed kept private` is a massive assumption. If the sender's machine is compromised, which you have no way of knowing, then all bets are off – Darren H Jan 17 '18 at 06:01
14

If two self-signed certificates have different public keys you cannot determine if these certificates were created by the same person or not.

If two self-signed certificates have the same public key you at least know that the same private key was used to create the certificates. If you assume that this secret private key is only known to one person you can deduce from that the same person has created both certificates.
If you instead must assume that multiple persons might have access to the same private key then you at least know that one of the certificates was issued by one person in this group and the other by the same or different person from the same group.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
1

In addition to the points made by other users, if the documents themselves are signed with MD5 or SHA-1, then you cannot trust that they were signed by the same person, even if the signatures are valid and have the same public key (which would normally be sufficient).

The reason for this is that both MD5 and SHA-1 have been found to have weaknesses that can be exploited to make an attacker controlled document appear to have been signed by the original author.

The SHA-1 attack is still very expensive, so could only be attempted by a very well-funded attacker, but MD5 is exploitable with relatively inexpensive hardware (effective real-world attacks have been mounted by university researchers).

Both attacks would be reliant on a signing oracle, so may not be applicable to your situation, but MD5 or SHA-1 are problematic, especially if you have well-funded adversaries.

James_pic
  • 2,540
  • 2
  • 18
  • 22
0

I think that the math behind the functions should keep you relatively safe, given that the public key in the certificate matches with the creator's public key.

From your question though, it seems that you are new to the concept of SHA digest and Digital Signatures (most signatures are self-signed). If you would like to learn the principles there a lot of websites and YouTube videos that would help. The basics are as follows. There are two functions, one for creation and one to check. The creation function takes the input as the SHA digest of the message and the creator's private key and gives an output as a digital signature. The check function takes input in the form of the message (it's SHA digest), the creators public key, and the digital signature to give out a logical output 'true' or 'false' depending on whether the digital signature is valid or not. Also note that the SHA digest of a fixed message doesn't vary. This is a great way to ensure data integrity and proves that a certificate is legit.

But a simple answer is, if the public key in the certificate matches with the creator's public key you are relatively safe. For example, two public keys having the same SHA1 digest is incredibly rare and tough to find. That can ensure that it is highly unlikely that SHA1 is the weak link, since you can cross-check the SHA1 digest of a key given with one calculated from the public key (They should match). You can also try to self-check the various digests mentioned in your question to ensure the legitimacy of the certificate. If the digital signature is invalid, your OS or application should pick up on that via in-built functions, if it doesn't apply the function by yourself. So in conclusion, cross-check the digests and the public key. For your initial question, if you trust that Document A was sent by a legit sender, then the public keys of both the certificates should match. If the attacker tries to pretend to be the original sender, it'll show in the digest and signatures.

Shubhanshu Dixit
  • 41
  • 2