I have a problem understanding the sence of a revocation certificate in gpg. If I create a revocation certificate of my key, if its stolen or lost, I can import it and my key is now revoked. If I upload my key now to a keyserver, my key should not be valid anymore, right? But anybody who has already my key, before I revoked it, can still encrypt messages to me, and the one who stole it can still decrypt the messages. Only new people, who download the key after the revocation from the keyserver see that the key is revoked and not valid anymore. Am I right with that?
Yes, you're right. The revocation certificate is a means to mark your key as invalid - in case you lost your secret key, or that your key has been compromised.
Of course, this information has to be passed on to all senders. Thus it is good practise to occasionally update all public keys from a key server - this adds all new signatures, new e-mail addresses, etc., and imports revocation information (if any).
In case that you are afraid that some adversary might intercept messages, it is a good idea to inform your common contacts (e.g. by mail) to refresh your key from a key server, or by sending them the revocation certificate directly.
A means to force your communication partners to update your key (at least from time to time) is by giving your key an expiration date. If the date approaches, you can modify your key and set a new expiration date. After that, upload the modified key to the key servers. Your communication partners will find out that your key has expired and will (hopefully) look for an updated key on the key server. This gives them your key with a new expiry date, or the revocation information.
Related
I have a question about protecting data against an untrusted end-user in the following scenario:
Basic feature to implement:
User logs into desktop app using username and password in order to have access to a subscription based software
The server respond with an encrypted token having a validity (30 days for example) and a Hardware Identifier specific for that one machine for which the user is now entitled. The server also responds with a public key with which the token above can be decrypted/checked
Every time the user launch the desktop app, if we are in an offline scenario we check the validity of the token by decrypting it with the public key, and then we can check if it is still within the validity period, and if it is on the correct Hardware as well (i.e. if the user did not just copy the encrypted files on a different machine and try to use the same account on more computers simultaneously)
Problem:
The scenario above has no protection against an untrusted user.
Example of possible attack:
The user decrypts the token using the public key
He now edits the token and sets a new Hardware Identifier, for the new machine he wants to copy the tokens
He edits the expiring date to 31.12.2099 for example
He generates his own private-public pair of keys
He encrypt the token again with his own private key
Now he can transport the encrypted token together with his own public key on the new machine, and as soon as he launches the desktop app in an offline scenario, the app has no way to tell that the token has been altered. It checks the authenticity of the token, but it can't check that the public key has been corrupted as well.
Every asymmetric encryption approach assumes that the end-user is trustable. For example when signing an app with a certificate, we assume that the user has no intention in attacking the offline trusted root certificates.
A solution I avoid would be to encrypt the private key or the public key within the code, but:
That is very very unsafe
That is not flexible in case you want to update the keys
It can be reversed engineered
After studying cryptography for a while I never realized that this scenario is so unsafe. Now I am wondering how a lot of already existing apps work in this scenario without exposing themselves to this so easy attack?
Thank you!
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.
I am new in apple developer. I have problem when create apns key for my app ( there 2 key service before).
Here is my capture screen
After a lot of searchs, I still dont know why? I read apple doc that say only using apn key to make ios app can get remote notification. Other key is not working. Please help me know it. Thanks.
Check your past keys, as mentioned here (click on "Read the Guides", then "Push Notifications"):
The Key Id and Certificate File is obtained by creating a new key.
Enter a name for the key and select the APNs service.
This key is used for all your apps, so if “You have already reached the maximum allowed number of Keys for this service” look back at your list of your keys for an APNs service key.
When the key is generated, make sure to download and back up the certificate file as it will not be accessible in the future.
Maybe you can check in your list of keys for the APNs service keys, and or try to delete/recreate said keys.
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.