This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Verifying Certificate Signatures
Verifying Certificate Signatures

Version management

Difference between version and

At line 1 added 42 lines
!!! Overview
[{$pagename}]
[RSA] is all about the [Computational Hardness Assumption] in mind with [RSA] in the real world is that all of the numbers involved have to be big to make things really hard to break using the best [algorithms] that we have.
!! How big?
We will look at our [Example Certificate] which was "signed" by "[VeriSign] Class 3 Secure Server [CA]."
From the [Example Certificate], we see that this VeriSign [Certificate Modulus] [n|Certificate Modulus] is 2048 bits long which has this 617 digit base-10 representation:
{{{
1890572922 9464742433 9498401781 6528521078 8629616064 3051642608 4317020197 7241822595 6075980039 8371048211 4887504542 4200635317 0422636532 2091550579 0341204005 1169453804 7325464426 0479594122 4167270607 6731441028 3698615569 9947933786 3789783838 5829991518 1037601365 0218058341 7944190228 0926880299 3425241541 4300090021 1055372661 2125414429 9349272172 5333752665 6605550620 5558450610 3253786958 8361121949 2417723618 5199653627 5260212221 0847786057 9342235500 9443918198 9038906234 1550747726 8041766919 1500918876 1961879460 3091993360 6376719337 6644159792 1249204891 7079005527 7689341573 9395596650 5484628101 0469658502 1566385762 0175231997 6268718746 7514321
}}}
(Good luck trying to find "p" and "q" from this "n" - if you could, you could generate real-looking VeriSign [certificates].)
[VeriSign]'s [e|Public Key] is 2^16 + 1 = 65537.
Of course, they keep their [d|Private Key] value secret. Before signing, [VeriSign] checked the validity of the contents that [Example] [Certificate] claimed on its [certificate] using a real-world "handshake" that involved looking at several of the requester's business documents. ([Enrollment])\\
Once VeriSign was satisfied with the documents, they used the [SHA-1] [Cryptographic Hash Function] to get a [Hash] value of the [Certificate] that had all the claims. In [Wireshark], the full certificate shows up as the "signedCertificate" part, which sort of a misnomer since it actually means that those are the bytes that the signer is going to sign and not the bytes that already include a signature.
The actual signature, [S|Certificate Signature], is simply called "encrypted" in [Wireshark]. If we raise [S|Certificate Signature] to VeriSign's [Public Key] [Certificate Exponent] of 65537 and then take the remainder when divided by the modulus "[n|Certificate Modulus]", we get this [Decrypted|Decryption] signature [hex] value:
{{{
0001FFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFF00302130 0906052B0E03021A 05000414C19F8786 871775C60EFE0542 E4C2167C830539DB
}}}
Per the [PKCS #1|PKCS 1] v1.5 standard in [RFC 2313] page-9,
* the first [byte] is "00" and it "ensures that the encryption block, when converted to an integer, is less than the modulus."
* The second [byte] of "01" indicates that this is a [Private Key] operation (e.g. it's a [Digital Signature]).
* This is followed by a lot of "FF" [Padding bits] that are used to pad the result to make sure that it's big enough.
* The [Padding bit] is terminated by a "00" byte.
* It's followed by "30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14" which is the [PKCS #1] v2.1 way of specifying the [SHA-1] hash algorithm.
* The last 20 bytes are [SHA-1] [Hash] digest of the bytes in "signedCertificate."
Since the [Decrypted|Decryption] value is properly formatted and the last bytes are the same [Hash] value that we can calculate independently, we can assume that whoever knew "[VeriSign] Class 3 Secure Server CA"'s [Private Key] "signed" it. We implicitly [trust] that only VeriSign knows the [Private Key] "d."
We can repeat the process to verify the rest of the [Certificate Chain]. Which implies that "VeriSign Class 3 Secure Server CA"'s certificate was signed by VeriSign's "Class 3 Public Primary [Certification Authority|Certificate Authority]."
!! But why should we [trust] that?
There are no more levels on the [trust chain|Certificate Chain]. The top "[VeriSign] Class 3 Public Primary Certification Authority" was [signed by itself|Self-signed Certificate] and is a [Root Certificate]. If we [trust] VeriSign and that VeriSign did the due diligence in issuing the [Certificate], then we [trust] the [certificate]
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop