I'm working through implementing the algorithm outlined by apple here for authenticating a player given a public key and signature, and I don't quite understand what they mean by
Verify with the appropriate signing authority that Apple signed the public key.
Once I've downloaded the .cer file, with NodeJS I can do something like this:
const publicKey = new X509Certificate(response.data)
console.log(publicKey.subject)
which will indeed show that the organization is Apple. If you look at some other implementations of this algorithm, it seems people are just checking "hey, is this a valid cert?", but not actually confirming with the signing authority.
In this case, the issuer of the certificate (I assume that a certificate authority is this is analogous with signing authority, but please correct me if I'm wrong) is DigiCert, Inc., so it seems like we'd almost have to somehow make some API call to them and ask "Hey, did you guys grant Apple this specific public key?"
Is this what apple means by "verify with the appropriate signing authority that Apple signed the public key."? Or am I getting signing authority confused and certificate authority confused?
Thanks!
Related
I am searching the algorithm about how SSL validation process is performed, but almost everywhere, they explain the certificate validation step as "certificate is checked by client" or something like that, but I wonder what is the scenario behind this.
What I know is:
When the client receives a copy of the certificate that belongs to which website/server you wanna attempt to handshake, there are some indicators that shows the public information of webserver (I think this is for matching the entries in your cached certificate entries, which your browser has installed.)
Once the client matchs a cached-certificate with the webserver's one, it starts validating it. It uses the public key of cached-certificate to decrypt the signature of webserver's one.(? [Not sure this because public keys are used to "encrypt" the data, not decrypt. Also this step may be totally wrong.])
Once it decrypts, it compares the signature between cached one and webserver's one. If it is same, certificate is valid.
I also heard about chains. I really wonder how a chain is known, and how to determine if the webserver's certificate just belongs to a chain.(?)
How SSL certificates are checked by client? I need the answer as step by step and clarified. Thanks :)
Edit:
I think the public key here is used for "decrypting" instead of "encrypting". So a public key is not responsible for encrypting everytime, it can also decrypt and don't encrypt some data. The magic here is that since the public key decrypts here, if you want to fake the certificate, you should have that CA's private key to apply the changes as encrypted (because only private key can encrypt the data). But now, another question comes... What if we decrypt it using webserver's public key, then change the entries in the signature, then encrypt it again using our own private key (we generate it manually, it doesn't belong to server.), which actually make us behave like a CA; and finally overwrite the certificate to hold our own public key which is able to decrypt the data encrypted with our own private key?
There is differences between Encryption and Signature.
Public Key is used by the client to encrypt data that only the server can decrypt with the Private Key of the server.
Public Key is used by the client to verify the signature of the data send by the Server that can only be signed by the Private Key of the server.
When the client wants to access a server, the server send you a certificate containing a public key. The client usually the web browser will check in his integrated CA's list certificates if it contains it.
If it contains it, the client continue and get the CA(Certificate authority)'s that authorized this certificate.
If it not found but the verification of the signature pass, the client will get a warning saying that the certificate is probably self signed and can be malicious.
If the client can't verify the signature, it means the certificate is not valid.
for the chain of trust you can check wikipedia :
https://en.wikipedia.org/wiki/Chain_of_trust
you need to be in this chain of trust to be register in the web broswer integrated "database" of CA's.
Hope it answers your question, best regards,
M
Put it simple:
Private Key -> Decrypt and Sign
Public Key -> Encrypt and Verify
Certification Authority
Is the authority that signs and guarantees the authenticity of the certification. If you trust the CA, then you trust also its certificates.
It's the same for friends: if you have a friend that you trust and this tells you "I have a friend that I trust", then you also trust the friend of your friend.
Chain of Certificate Authority.
You can have multiple intermediate CA, for example, you can have
Root Certification Authority
Intermediate Certification Authority for WebServer signed by Root Certification Authority
Web Server Certificate signed by Intermediate Certification Authority for WebServer
Intermediate Certification Authority for signing code, signed by Root Certification Authority
Etc
Why?
Because in case one of the intermediate authorities is compromised you can revoke only its child certificates.
At the enterprise level, each CA has a different level of security, for example, the Root Certification Authority can be stored inside a safe and used only when there are two o more admins.
For the intermediate, instead, maybe only one Admin can manage it.
References
How SSL Works
How HTTPS Works
Wht digital certificates
I'm new to asymmetric cryptography (public-private keys) and has a fundamental confusion:
I understand that once a person has broadcast his public key to the network, the following communications become safe using the public-private key paradigm.
However, how do you make sure the public key received is valid at the first place? For example, if Bob wants to establish a secure communication with Alice, with Eve eavesdropping in the middle, how do you make sure that Bob receives the real public key from Alice, instead of the fake public key forged by Eve?
Thanks!
Cheers,
M.
Public Key Infrastructure (PKI).
You have a third-party trusted authority that issues certificates to different people/companies. You don't only trust the people, but also the Certification Authority (CA).
The Certification Authority must ensure and validate that the people/company that is buying a certificate is in fact who it claims to be.
The verification is done by signing a the certificate using a private key (from this CA), then both peers in the connection will check that the certificate was signed by a trusted CA and validate the connection.
In you example, Bob will sign the certificate in a CA that Alice trusts.
If Eve tries to sign a certificate in this CA, claiming to be Bob, this will be rejected, because the CA will validate its authenticity. Try to buy a client certificate here to see: https://www.verisign.com/
Another example is your browser, it only shows that a trusted connection is done with StackOverflow, because it trust on Let´s Encrypt, which issued the StackOverflow.com certificate.
Every browser has some default CAs that are already trusted.
The public key would be signed by another authority. Check if this authority is genuine and renowned. If it is unknown then try to further check its signing authority and see if its a renowned one.
The concept of trusting this public key is based on basing your inherent trust in authority which signs this certificate. Signatures are mathematically verifiable so they cannot be forged unless there's an issue with implementation or mathematical algorithm itself.
So in a nutshell, try to see the signing authority of the certificate and if it is something you trust.
The certificate authorities(CA) or web of trust(WOT) model shall help you in ensuring the authenticity of public key.
The Certificate authority is a centralized entity that issues digital certificate that certifies the ownership of a public key by the named subject of the certificate. It acts as a trusted 3rd party, trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.
The web of trust is a decentralized trust model to establish the authenticity of the binding between a public key and its owner . In a Web of Trust, everybody is a kind of CA. Every user signs certificates for whoever he wants. It relies on value of trust or trust relationships between regular users.
Web Of Trust model operates such that if we verify that A's certificate is actually for A and we verify that B's certificate is from B, A and B can both verify that C is in fact C. Now, when C want's to interact with us, he can provide his certificate which is trusted by both A and B. Since we trust A and B , we can conclude that it is highly probable that C is actually C. This works since we expect that A and B weren't both working together and C had to have convinced them both that he was ok.
I am getting my hands dirty with https, ssl, PKI stuff. And there is one thing that I dont quite understand with self signed certificates.
Say I want to create a self-signed certificate and send it over to my friend whenever we want to establish a secure connection.
So the steps are:
create a private key.
create a public key.
sign the certificate with my public key.
So when my friend gets my certificate he has to verify that the certificate he gets is mine, he needs to decrypt digital signature. But in order to decrypt it and verify he has to have my private key. So, I am a bit confused here.
You've got things reversed. You sign with your private key that only you have.
You include your public key with the signature so the recipient can "verify" that the signature was calculated correctly.
But a self-signed certificate gives no assurance of the sender's identity since there is no way to independently verify that the signed data/document came from the supposed signer.
Newbie question: some vendors propose solution like generating dynamic certificates to allow user who haven't classic certificate to sign documents. But why not just generate private/public keys alone instead of bothering with certificate format ?
The purpose of the (public key) certificate is to bind the public key to the identity of its subject (i.e. the owner/entity associated with the key pair), and possibly various attributes telling you what the certificate may be used for. (You may be interested in this question on Security.SE.)
You always sign with the private key (not the public key or the certificate), but the public key or certificate are often attached with the signed document.
If you have an explicit list of public keys you know and can link independently to a user, you don't need a certificate.
The certificate allows third parties (who have signed the certificate) to assert the binding between the identifier and the public key. Even if you don't know that identity in advance, you can link the signature to the signer's identity as long as you trust the entity that signed the certificate.
Dynamically generated certificates may not be very useful in this case, unless you trust the party that generates the certificate dynamically (I'm not sure if you meant the tool itself or perhaps a website that you would also know).
Often, X.509 certificates will be used just to attach to that signature, because the tooling requires it, whereas you may be able to match the public key against an identity you know directly in the tool with which you verify the signature. Sometimes, it's also just done in anticipation of a case where it will be useful one day.
For example, if you publish your own artifacts to the central Maven repository, you will be required to sign it with your PGP certificate (often only referred to as the PGP public key). Yet, no verification of the certificate is made at all during the process (PGP certificate with only its self-signed signature is good enough). This makes this process relatively pointless in this case, but makes it possible to be stricter in which artifacts you want to use, if you're able to verify those certificates later on.
It's the same but you need a third party to consent that private key belongs to whom ever you think it belongs to.
Signing proves first of all authorship (or approval) of the document by some person. And the key alone won't prove anything. This is what the certificate is needed for - some certificate authority signs the certificate of the user and certifies that the keypair belongs to the person (or legal entity) to which the certificate is issued. The reader of the document can ensure that the signature is valid not by just computing the signature itself, but also by validating the certificate and seeing the name of the certificate owner.
I don't quite understand what vendors can issue certificates dynamically - issuing certificate in such way that they are not self-signed (and self-signed certificates make little sense in context of document signing) requires that the private key, used for signing the certificate, should be embedded into software of those vendors, and as such it's also prone to misuse.
I read an article about digital signature (link) and have question as follows.
Let's say Alice wants to send a message to Bob. She need to let Bob know the message is from her. So she encrypted the hashed message with her private key into a certificate. Then Bob can decrypted the message with public key when receiving it. Bob can know it is from Alice if the hash code of the message matches the hash code which is decrypted from certificate. Here we have the assumption that Bob already knows the public key. What if the transmission of public key is already attacked? Bob might use the wrong public key to decrypt the wrong message and get that the message if from Alice. Is there any protocal or policy to avoid the attack against public key? And shall we？
Yes, the authenticity of public keys is a key component of applied cryptography. I can issue a public key that says "I am the website of your bank, trust me", but you shouldn't really trust it. Different schemes have been developed to establish authentication of public keys. One approach is the web of trust model in PGP and GnuPG, others are PKI and Kerberos. One of the main difference between these approaches is where you place your trust. I provide a simplified description only, you have to read about them to learn about the exact details (you wouldn't base your security on an extremely short summary, would you?).
In the web of trust there are some people who you trust, and you (ideally) verified their public keys personally. You can trust other public keys if they have been signed by several people bearing your initial trust. Using these trusted individuals you can check more and more keys.
In PKI (Personal Key Infrastructure) you trust several Certificate Authorities (CAs) and accept their public keys. You trust them that they thoroughly check the identity of key holders before signing their public keys. The combination of public key + signature from a CA (and some other data) forms a certificate. The PKI is used in SSL/TLS, it is the underlying infrastructure of the secure web. You use it when you read your mail on a web interface, when you do online banking, etc. If a CA is compromised, then every certificate signed by the CA will be come insecure.
In Kerberos is designed for computer networks and the key server is the single point of trust. It provides mutual authentication and a unique symmetric encryption key for clients and servers. The key server checks the identity of clients by a secret shared only between the key server and the client. Kereberos is used, for example, in Windows, AFS, Grid computing.
your answer gave me much of insight into the question. And also, I would like to put the wikipedia link http://en.wikipedia.org/wiki/X.509#Security here. Coz there is one stentence in the article solve my question "who certificate the Certificate Authority"
This is an example of a self-signed certificate, as the issuer and subject are the same. There's no way to verify this certificate except by checking it against itself; instead, these top-level certificates are manually stored by web browsers. Thawte is one of the root certificate authorities recognized by both Microsoft and Netscape. This certificate comes with the web browser and is trusted by default.
Just in case some one has the same question.