We want to add automatic software updates to our application, but our company isn't yet ready to buy a code-signing certificate from a trusted root CA, so we'll be using a self-signed certificate to sign code updates (.exe and .dll) for now.
Question: how to verify a binary signed with a self-signed certificate, without having to install the certificate, using Microsoft's Cryptography API? The .cer file to check against will be bundled with the application. Or is it simpler to use a generic Crypto library?
You can skip the whole X509 thing, after all you don't really need it if you're going to be using your own certificates...
For what you want to do, first you have to generate your RSA private/public key pair. Then you store the public key in your application.
When you have an update, you sign it on your site, by getting the MD5 or SHA-1 or whatever hash you want to use; then you encrypt that hash with the private key. The installed applications fetch the update and the signature (the encrypted hash); when the application gets the binary file, it computes its hash, then decrypts the other one using the public key and compares them. If they're identical then it's a valid update, otherwise you reject it and warn the user or something.
With X509 certificates that are self-signed the mechanism is going to be exactly that, but the public key is going to have a bunch of additional data like the identity of the issuer which will be the same identity of the certificate.
I seem to recall hearing of a way to enable self-signed certs some years ago, back in the Win2k days, but it was very hacky, not at all suitable for public deployment and has probably been "fixed". If you do think about using some other crypto library, or developing your own, take care: it's very hard to distinguish good crypto from bad crypto.
Related
I am a developer with very little experience of encryption. I am trying to learn more about Encryption and specifically SSL in my spare time.
Say a trusted company has a file (notepad) that contains a load of personal and confidential information. Say I wanted to ask them to send this information to a me to analyze. How would I do this?
My research is telling me that I would have to:
1) Create a self signed certificate
2) Generate the public and private key
3) Issue the public key to the trusted company and keep the private key
4) Ask the company to encrypt the information using the public key and then send it to me
5) Decrypt the file using the private key
Is that correct? How would I do this?
Should the certificate be signed by a Certificate Authority in this case as I would manually be issuing the public key to the trusted company (they know it comes from me).
As I said I am relatively new to this subject.
SSL is a protocol for encrypting network connections. It's not really relevant for manually encrypting and decrypting files. (It's also insecure and deprecated; TLS should be used instead.)
If you want to manually encrypt and decrypt files, yes, you could use a self-signed certificate and just give the public key to the company that'll send the file. However, you have to make sure to give them the public key in a way that can't be intercepted — such as physically handing it over on a flash drive, not emailing it — or you're vulnerable to a man-in-the-middle attack: someone could intercept the public key and give the company a different one instead. (If that happened, the company would unknowingly be encrypting the file for the attacker to decrypt, and the attacker would then re-encrypt the file with the real public key and send it along to you.)
If you're doing this manually and you deliver the public key in a secure way, you don't need to involve a certificate authority. The purpose of a certificate authority is to vouch for the authenticity of a certificate when it's delivered over an insecure channel. For example, when you visit stackoverflow.com, your browser gets a certificate (with a public key) from the web server. Since this certificate wasn't personally given to you by SO staff, how do you know that the web server is the real stackoverflow.com, not a man-in-the-middle attacker intercepting your connection in order to hijack your account? The website's certificate is signed by a certificate authority — DigiCert, currently — that says DigiCert has verified that it's real. Your browser is configured to trust that signature from DigiCert, because the browser developers have verified that the company is trustworthy.
PGP and GPG are good tools for securely exchanging encrypted files. They use a "web-of-trust" model based on securely exchanging certificates, rather than relying on a certificate authority.
The question may sound a bit stupid but I really want to know this.
When we download a file, say abc.exe, it is digitally signed with some digital certificate of some organisation. Why do we need to install that certificate? What is the use of it? What if we dont install it?
When I run certmgr.msc in my windows system, I see some certificates already installed. What do they mean?
If you get signed material, you may want to verify the signature.
Digital signatures usually are created using a private key and can be verified using the associated public key.
Certificates essentially are transport containers for public keys with some extra information. Thus, to verify signatures you usually need the certificate of the signer.
You install certificates to make them known to your system (to allow for signature verification) and to tell your system to trust material signed by the associated private key.
As having to install certificates by each and every party you want to trust is too much work, certificates can have hierarchies, some root certificate may be the issuer of multiple other certificates, and by trusting that root you implicitly trust those other certificates the root issued.
For more details you may want to ask on https://security.stackexchange.com/.
The RSA algorithm used for encryption is used for digital signatures.
Use of RSA for a signature is as under:
1. First, a message digest is calculated.
2. The private key is used to sign the digest of the message.
3. The signature is appended to the message and transmitted to the recipient.
4. The recipient calculates the digest of the received message.
5. Then, verifying the signature requires extracting the signature from the message
and using RSA on the signature with the public key.
6. If the result of the transformation and the newly calculated digest are equal, the signature is valid.
I have a small question about GPG certificates and certificates authorities.
I am using GnuPG to sign a tarball that I am hosting on my server. I would like that users who wants to download this tarball to be able to encrypt it using my public key.
At the moment, I'm storing my public key on another server that I own. There are 2 issues with this:
The key isn't "trusted", and the user get a warning
In the same idea, because the key isn't trusted, if the key is maliciously changed, the user won't see anything
I've read a bit about cryptography solutions in the past, and know a little bit how X.509 CA work, but I don't really understand how it is for PGP keys. I've tried to use my SSL (trusted) certificate in GPG, but it always fails (maybe there is an option I haven't found?).
If it's not possible to use my SSL certificate, how can I "register" my PGP certificate to a CA?
Thanks!
Best,
Thibault.
For all practical purposes, X.509 certificates and OpenPGP key pairs live in separate worlds. X.509 certificates are trusted hierarchically (building certificate chains) and OpenPGP keys are trusted on peer-to-peer basis.
As the technologies are incompatible, they are not easily replaceable by each other. To let users trust your OpenPGP key, you can publish it in one of OpenPPG key repositories (keyservers), and hope (or suggest) that users do use it as a trusted source of OpenPGP keys.
Alternatively, you can use your server's certificate to create a detached PKCS#7/CMS signature of the archive you distribute, but unlike OpenPGP there are no widespread tools available to check PKCS#7/CMS signatures on end-user computers. (Well, maybe OpenSSL will work for your user audience.) Note that KeyUsage of the server's certificate probably won't be appropriate for signing, so the users will get a warning.
Please note that OpenPGP keys are called "keys", and X.509 certificates are called in this way too. There exist no "pgp certificates" as well as no "ssl certificates".
I am developing an html application where an user has to first login using his digital certificate. After login he has to perform encryption and decryption of data using his digital certificate.
Now in case when the certificate is available in the form of .pfx file then we can just install it and the certificate appears in the container and we can use it during login and during encryption and decryption.
This works fine in case if we have .pfx for our digital certificate.
But now i want to enhance it for etoken's(security token). I dont know much about etoken's. The problem is that how can i use the digital certificate stored in it while login?
Also how should i use the private key stored in it while decryption?
Can anyone please tell me about any tutorials (if any) which will explain the usage of etoken and the CryptoAPI's.
As I mentioned in the answer to your previous question, Windows CSPs map the certificate from hardware to Windows certificate storage, so this is transparent to you. If you can access the certificate via Windows certificate storage API, then you don't need to care where the certificate is actually located.
Note that you can't transfer a private key to the server, i.e. you would have to use a client-side module (either ActiveX or Java applet) that will perform operations locally. This is not specific to certificates on hardware, but also to certificates which have non-exportable private keys.
I'm creating a webpage to take sensitive customer information and wish this to be on an SSL secured page.
Ive been asked by a CA to provide a CSR.
I was planning to install OpenSSL on a server and create one of these.
Does this mean that the server I create the CSR on will be the same one I have to install the certificate they provide me or can I install it somewhere else?
What links the certificate they provide to the CSR I create?
Thanks for any help.
When a key pair (public and private) is generated, such as with OpenSSL, a CSR is also generated. The CSR is sort of a wrapper that contains your Organization info with the public key.
This is also the part of the pair where the CA will sign upon.
Once you have received the signed certificate (after paying companies like VeriSign, GoDaddy) you should be pairing the signed certificate back together with the initially generated private key and together they work in the app in which you wish to secure content transmission with. E.g. Web servers.
The key pair, and CSR files generated usually CAN BE moved to other hosts/servers. Only in cases where the key pair generation mechanism involves hardware (such as some nCipher devices) will you not be allowed to move to other machine.
It doesn't matter, where the certificate signing request (CSR) is being generated.
Just make sure, you keep the private key. Otherwise the issued certificate will be useless, as it's the key that "links" your CSR to the certificate.