I know that some things in a signing key (like the validity period) can't be changed. Can the owner name change? If yes, how can I do it using keytool?
Interesting question. I've done a bit of digging, and it seems like it isn't possible. See this detailed answer on the security stack exchange. While you (and I) often think of certificate as just a public key, the certificate is the public key combined with the owner (Distinguished-Name) information, and the certificate hash is a hash of this information. So if you change the Owner information, you change the certificate, and so change the certificate hash. This is true for both APK Signing V1 and V2.
Related
As I can see, in Windows, the Digital Signature tab of an EXE file will show the Company Name, City Name, and Country Name of the company.
Is the user able to find the detailed address of the company from the signature? The situation is the same for OV and EV code signings?
Thank you.
Information appearing on the Digital Signature tab come from the 'Subject' field of the certificate.
This information is provided by the company when signing keys are generated.
Then, those keys are used to generate a Certificate signing request (CSR) who contains this information + public key.
This is this CSR who is transmitted to the certificate authority.
The certificate authority will then sign digitally the certificate with his proper key, after validation of information present on the CSR. It will not add any further information about the company, only validate and sign. The validation process of the company by the authority will be different for OV or EV, but information present on the certificate stays those provided by the company on the CSR.
The detailed address of the company will appear only if it was provided when signing keys were generated.
This is not typical information required on a certificate, but the company can choose to add personalized information on the Subject field.
I am not aware of any certificate authority who require the detailed address on CSR.
I don't believe so as it would not be very secure to display the company's detailed information. This could lead to someone breaking in or harassing workers where Microsoft could be blamed as they let the company's address go public.
Data about an exe file made with visual studio is created like this inside the AssemblyInfo.cs (in C# projects) in the properties. This is all the data that can be found if I'm correct. Every application made in visual studio will have something like this, I'm not sure about C++ projects, but it should be something around the lines like this.
I have 2 code signing certificates, for both CSR is created same way, also import and export is done same way. The only difference that I see is that one of certificates Common name contains Quotes, and the other doesn't.
e.g.
some cert and
some "cert"
CSR creation
Request format PKCS #10
disabled "Strong private key encryption"
Entered Common name, Organization, Locality, State, Country
2048 bytes for private key
set private key exportable
Import
place all certificates in Personal store
Export
Include all certificates if possible
Enable certificate privacy
encryption algorithm TripleDES-SHA1
Misleading thing is that this Common name value is NOT taken from the value I entered when I created CSR request
I am using those certificates to sign Winforms applications in Visual Studio. Certificate without Quotes in common name is working correctly (i.e. when I install application user is not getting security warning about unknown publisher), but when I install application which is signed with the other Code signing certificate (with Quotes in Common name) - it does not recognize Publisher. No error when published my application. When I take a look at setup.exe properties in Windows Explorer I see a Digital signatures tab which contains row for my certificate.
I tried to sign files with signtool and then verify - it said that certificate is valid.
I tried to get help from godaddy.com where I bought my certificate, they said that it should work with quotes, too, but didn't offer help to solve the issue. Rekey also didn't help.
I see that there are some suggestions to use Pre Publish, Post Build tasks, but I am not using those for my first certificate which is working.
So, is anyone here using code signing certificate for Winforms application with common name having quotes in it? Or maybe anyone knows about this problem and how to solve it?
Had to revoke (common name which is entered when creating CSR is not taken into account, so rekeying is not enough!) my code signing certificate and create from start without quotes/brackets in company name.
So this means, you will have to wait again for few days, because verification process is made from start again. When you will be contacted by issuer, they will verify / ask you about company name - make sure that they do not include quotes/brackets.
Revoking means that you will basically have to buy your certificate once more, because after you revoke it (at least in godaddy case) in your account you don't have options to create it again. So, you have to contact support (use call center and not chat ;)
I am a new developer working on an open source application and I am trying to figure out how one signs a program.
I understand why code signing is a thing, and I know how to get a certificate (from a CA or individually), but I can't find anything explaining the actual process of signing itself once you have your private key.
How does one sign code with a signing certificate? Specifically, do you sign the source code, the built executable, something else entirely? Do you run a specific app, or include something in the code?
related but discrete question: What to do with the code signing certificate?
You have a code signing certificate which contains a private key and a public key.
You calculate a cryptographically save checksum of your code and data, encrypt it with your private key. You add the encrypted checksum and your public key to your code.
Now anyone can calculate the same checksum of your code, decrypt the encrypted checksum with the public key, and compare them. If they match, then it is proven that the code was supplied by someone who has your private key. If they don't match, then it is proven that this code is not the same as the on of which you encrypted the checksum.
To be useful, the operating system would perform this kind of test before any application is allowed to run. And the public key would be signed with well known private key owned by the OS supplier, and would likely be accompanied by data that can be used to identify the owner of the public key.
Obviously EvilHacker could create malware and code sign it. So the fact that it is signed is meaningless. But you would also have the identity of EvilHacker, or the operating system wouldn't start the application. So the operating system will never allow you to run a hacked application or one where the owner of the public key is not known to the creator of the OS.
The second worst a hacker can do successfully is to completely remove the code signing and give you unsigned hacked code - the OS will likely ask you whether you want to run unsigned code or not, or not allow it at all.
The worst a hacker can do is either to con the os owner to accept EvilHacker's code signing certificate, or steal a code signing certificate and create malware that is actually correctly signed.
I'm developing an application to manage file and email encryption using (primarily) PKI. I have a Public Keyring with a list of contacts and their Public Keys.
Referring back to the olden days when I used PGP, I recall a requirement to sign public keys with your Private Key.
Is this a necessity on PKI and if so, what does this signing achieve? Is it bad practice to simply hold a list/database of people's names (and email) and their Public Key? Surely if their public key is - in any way - tampered with the encryption would fail and as you choose who you're sending or sharing the encrypted data with, even if a 'successful tamper' went unnoticed, the encrypted data wouldn't end up in the wrong hands anyway?
The whole thing about signing a public key with a private key is useful when you have a dedicated key-pair that you use only for signing, and then other key-pairs that you use for encrypting. This dedicated key-pair is your "trusted" key-pair that is somehow known to be legitimately attached to you (often by having it signed by a certificate authority or by having many trusted people sign that they have verified it's connection to you.)
You use this "trusted" private key to sign your not-quite-as-trusted public key. This way, people can un-sign/decrypt your new public-key with your trusted public-key. This is only mathematically possible if it was signed by your trusted private-key.
This process helps people to be sure that this new public-key actually belongs to you.
I have another question to security in the web.
If I understand it correctly certificates are for identify who you really are. So the man in the middle attack isn't possible.
But when I see this image:
http://upload.wikimedia.org/wikipedia/commons/thumb/2/2b/Digital_Signature_diagram.svg/800px-Digital_Signature_diagram.svg.png
I think a man in the middle attack is possible. You could split the Signature, the certificate from the data. Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.
What I also not understand in this picture is where the certificate gets checked, on the verification side.
thanks.
SCBoy
Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.
The problem is that the receiver will then look at the fake signature and see that it does not match the certificate of the real sender.
You can only create signatures that match a given certificate when you have the correct private key for that certificate (even though the certificate itself is public, that is the magic of asymmetric cryptography). This private key is being kept secret by the owner of the certificate (the original sender of the message).
The man-in-the-middle is prevented by distributing trusted certificates in advance.
You have to trust the authenticity of the certificates, either by trusting them directly (root certificates) or by trusting a chain of signatures on the certificate leading up to one that you trust.
If the man in the middle can make you believe that his fake certificate is the real deal, then the whole system fails.