We have templates in our ADCS Microsoft PKI infrastructure for multiple uses. We do not want the certificate used for web server SSL to have the private key be exportable, so we have that option unchecked. When a user goes through the AD enrollment policy to request a certificate, they can select the option on the key options to make private key exportable even though we have marked on the template to not have the private key be exportable. They then get a certificate with an exportable private key even though we unchecked that on the template. We have not seen a way to stop it.
We have deleted the template to issue and redid the base template without the exportable private key option yet the request user can still get it. We have created new template without the option and issued the oner and they can still request the private key be exportable and get a certificate like this. We don't see a way to stop it. What are we misunderstanding?
What are we misunderstanding?
Template is a template, it is not something that is enforced in all aspects. Template provides default settings to minimize user input during enrollment. Almost every template setting can be overridden by client if necessary. Moreover, CA is not able to validate how the key was generated. This requires some form of key attestation that guarantees that the key is generated securely and stored on a tamper-evident chip (TPM, HSM, for instance). For software-based keys there is no such possibility.
This means that you cannot enforce non-exportable keys via templates.
Related
I'm working on a distributed application, and we need a way to authorize clients. Every client has a PGP keypair associated with them, and we require them to enter their private key (which is not stored) through which their pubkey is derived and used to identify clients and modify their fields on the distributed database.
Now, considering user experience, entering a private key on a website whenever you need to do something is troublesome. But we also cannot maintain a central database for username/password based authentication as that creates a single failure point (not what the distributed application is meant to do)
I am hoping there is some way to get an easier to remember human readable descriptor of the private key which can be used to authenticate if something like that exists. Any other ideas are appreciated too.
I'll throw a bunch of ideas to clarify the question:
Are you certain that PGP is suited for your needs?
I feel like you should provide some more details to be sure:
- How are the private and public keys used exactly? I understand the following : user inputs its private key, information is decrypted and modified, public key is deduced from private and used to encrypt the updated information.
- How is this different from using a regular password and being able to authenticate the user and encrypt data?
- You seems to send private keys on the network, and they should remain private.
How you could use a regular password:
User has a password, your application uses a function (e.g sha256, KDF,...) to make it usable by classical encryption algorithms (e.g AES). With the same (not stored) key, you can then encrypt and decrypt datas. You just have to make sure that decryption is valid, by adding a known value at the beginning of the data (e.g a part of the key).
Quick example:
password: "WeakPassword"
key: sha256("WeakPassword"+"MySalt") = 493e3ae...b2eec8ef
Decrypt(data,key)
clearData = "493e3ae{123;456}" //valid, because you can check the beginning
Encrypt(clearData,key)
Advantages: usable passwords, faster symmetric encryption
Use a QR code
If you stick to PGP and have a camera available it is pretty handy.
You could also use hexadecimal, base64, ... but for a 2048 bits RSA key, that still gets you hundreds of characters.
I have started learning GPG and I am a bit confused about the infos I have found. The GnuPG documentation says that
A signature is created using the private key of the signer
But at the Apache's site, they say:
The signature file is a digest of the original file signed by a public key...
And on the same site, in another section, they say the following:
A digital signature is created from an original document using a private key.
Now I suppose that the process of signing involves signing the hash of a release using the private key of the holder and not the public one like Apache says in the second link I have posted, or am I wrong? Otherwise, how could someone be ever able to decrypt the hash of a release signed with a public key if he/she doesn't have the private key of the holder?
Then, could someone simply explain in what the processes of signing and verifying a signature consist and what are the passages, e.g. for a software release like Apache Maven?
TL;DR: There is a mistake in the documentation, your understanding of signatures is right.
The signature file is a digest of the original file signed by a public [sic, this is should be private] key...
Signing a document usually is performed by calculating the hash sum of the document (asymmetric cryptography is very slow for large amounts of data), which finally is encrypted using the private key, so anybody can decrypt it using the public key. If the decryption process results in the same hash sum as is calculated from the original document, it must have been encrypted using the private key - which is only known to the signer; thus the authorship is verified.
Encryption (leaving apart the aspect of hybrid cryptosystems like OpenPGP is, but the general concept stays the same) works the other way round; the public key is used for encryption, so only the private key can be used to decrypt the information.
I added a bug report for the documentation issue (closed/fixed since 2015-07-29).
Then, could someone simply explain in what the processes of signing and verifying a signature consist and what are the passages?, e.g. for a software release like Apache Maven -> https://maven.apache.org/download.cgi?Preferred=ftp://apache.mirrors.tds.net/pub/apache.org/ ?
You need to fetch the public key used for signing the software (usually, you will download it from a keyserver using gpg --recv-key [key-id].
Verify the key's integrity, for example by speaking with the developers, your web of trust, the products HTTPs-encrypted website (depending on how paranoid you're at verifying the authorship).
Issue a signature to certify the key if it is not already verified through your web of trust, if you don't want to create a public one, there are also local signatures which are never transmitted to the key server network.
Finally, use gpg --verify to check that the signature was indeed issued by the product maintainer's key.
This topic continues to confuse me. I thought I'd write out my current understanding and hopefully find out the things I'm right about/things I'm wrong about.
When you create a development certificate, there is a concept of a public and private key. The certificate available thru the provisioning portal holds on to a public key, while your private key is stored within your keychain. In order to code sign your app, you've got to have both.
In order to run an app, the device must have a provisioning profile, which essentially holds on to an app identifier, a set of recognized certificates (the app must've been signed by one of these certificates), and a set of device identifiers (which indicate which devices are allowed to run the app).
The 'recognized certificates' have references to the public key, while the private key is essentially passed on by the app.
Thus, with regards to the App Store, we can think of a normal device as coming with a default prov profile that already has apples 'public key' and apple performs their own code sign operation before distributing whereby they add their private key.
Perfect? Close? Way off? Insane?
For what it's worth, here is my updated understanding:
A Provisioning profile is a file that tells you which apps (via an AppID), signed by which developer (via the certificate) can run on which devices (the UDIDs).
With certificates, there is a concept of a public and private key. Public and private keys are mathematically linked such that one can encrypt the plain text, and one can decrypt the cipher text. Certificates allow apple to ensure two things: 1, that only registered developers can distribute their code, and 2, that the code that is being distributed isn't altered on its way to your device.
When you build your code in Xcode, you 'code sign' your application with the private key located in your keychain, thereby 'locking' it. In order to unlock/decrypt the code, the destination device must have access to your public key. The device gets the public key from your certificate that is included in the provisioning profile.
In order to verify that the code remains unchanged on its way from the developer to the device, your certificate includes an algorithm that can convert your code/data into what is known as a 'digest.' On the developer side, the data/code is run thru the algorithm, generating into a separate digest, which is then locked with the private key.
When the app package is received by the device, the device can ensure the code hasn't been altered by doing the following: unlocking the digest with the private key, running the unencrypted data thru the algorithm (remember, the device can access the cert thru its prov profile), and making sure the result is a digest identical to the one sent over from the developer.
Beyond that, the prov profile need only check the UDID of the phone, and make sure the AppID from the profile matches the identifier in the app.
The reason we don't need separate prov profiles for apps from the appstore, i assume, is because each iPhone ships with the public key used by apple to code sign distribution apps.
Ray Wenderlich has it explained reasonably well here. To improve your description, instead of
The 'recognized certificates' have references to the public key, while
the private key is essentially passed on by the app.
I would say:
The app .ipa includes a developer certificate. The developer
certificate is signed with your private key - as well as with the
official Apple private key.
Thus, by verifying the developer certificate with Apple's and your public keys, the iPhone can verify that:
you are the developer of this app
you have been certified by Apple for app development
this app is allow to be run on the iPhone (as long as there is a provisioning profile on the phone that refers to this developer certificate).
Your private key is not stored in any of the certificates or profiles, it is only used for signing. Not sure whether the public keys are stored. In order to be fully secure, the phone should fetch the public keys from Apple when verifying.
I need to write a code to check the validity of the digital certificate present in an etoken.
I am not familiar with etokens. Can anyone please answer my following questions,
How to access the digital certificate content from etoken?
Can we access the private key stored in etoken?
When we plug the etoken to an computer then does it copy the digital certificate on the computer or not? If yes then where does it copy it?
I need to write C++ program for the same. Can we use Cryptographic API's (like CrypImportKey() CryptExportKey() ) provided by Microsoft for the above requirement?
"etoken" was the name of one of first USB cryptotokens produced by Aladdin. What you are asking for is usually referred to as security token. This is a hardware device with it's own memory, in which certificates and private keys are stored.
Tokens need drivers to be installed in order to work properly. The driver set includes implementation of CSP (Cryptographic Service Provider) for CryptoAPI. CSP does the job of presenting certificates, stored in the token, to CryptoAPI. To answer your questions:
Via CryptoAPI or PKCS#11 interface (drivers for both are supplied by the vendor).
You can perform certain operations with the private key by calling the appropriate API. But the key itself is not extractable.
I can't say for sure but for me it looks like certificates are copied to in-memory certificate store for speed of operations.
In relation to your second question, I believe it is possible to access the private key on the security token. The security token had to be pre-programmed and loaded with a private key somehow. Also, the last time we renewed our certificate, we did it online, using the issuer's web interface which installed an ActiveX module that uploaded the new certificate to the device. I don't know if this procedure also uploaded a new key but possibly not, since I don't believe you need to change your private key to create a new public certificate for yourself (which needs to be signed by the issuer to be trusted I believe).
Sorry I might not make much sense as I am new to the whole idea of Public Key Infrastructure.
If someone else could validate/invalidate my claims, please share your knowledge.
EDIT: I found this hardware hack for Alladin devices: http://seclists.org/bugtraq/2000/May/48
Basically, it is possible to read the date on the eToken but it requires a direct hardware interface to the device's on-board memory.
I have three questions regarding SSL that I don't fully understand.
If I get it correctly, a server A submits a request to a certain CA. Then, it receives (after validation etc.) a digital certificate composed of a public key + identity + an encription of this information using the CA's private key.
Later on, a client B wants to open an SSL communication with A, so A sends B its digital certificate.
My question is can't B just take this certificate, thus stealing the identity A - which will allow them to authenticate as A to C, for example. I understand that C will decrypt the certificate with the CA's public key, It will then encrypt its symetric key which will only be decryptable by the real A.
However, I do not see where authentication comes to play if B can actually steal A's identity. Unless I am missing something.
Second question: Why use hashing on the certificate if a part of it is already encrypted by the CA? Doesn't this mean that no one can mess around with a digital certificate (in high probability) anyway?
If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.
Thank you very much.
An SSL identity is characterized by four parts:
A private key, which is not shared with anyone.
A public key, which you can share with anyone.
The private and public key form a matched pair: anything you encrypt with one can be decrypted with the other, but you cannot decrypt something encrypted with the public key without the private key or vice versa. This is genuine mathematical magic.
Metadata attached to the public key that state who it is talking about. For a server key, this would identify the DNS name of the service that is being secured (among other things). Other data in here includes things like the intended uses (mainly used to limit the amount of damage that someone with a stolen certificate can do) and an expiry date (to limit how long a stolen certificate can be used for).
A digital signature on the combination of public key and metadata so that they can't be messed around with and so that someone else can know how much to trust the metadata. There are multiple ways to handle who does the signature:
Signing with the private key (from part 1, above); a self-signed certificate. Anyone can do this but it doesn't convey much trust (precisely because anyone can do this).
Getting a group of people who trust each other to vouch for you by signing the certificate; a web-of-trust (so called because the trust relationship is transitive and often symmetric as people sign each others certificates).
Getting a trusted third party to do the signing; a certificate authority (CA). The identity of the CA is guaranteed by another higher-level CA in a trust chain back to some root authority that “everyone” trusts (i.e., there's a list built into your SSL library, which it's possible to update at deployment time).
There's no basic technical difference between the three types of authorities above, but the nature of the trust people put in them is extremely variable. The details of why this is would require a very long answer indeed!
Items 2–4 are what comprises the digital certificate.
When the client, B, starts the SSL protocol with the server, A, the server's digital certificate is communicated to B as part of the protocol. A's private key is not sent, but because B can successfully decrypt a message sent by the other end with the public key in the digital certificate, B can know that A has the private key that matches. B can then look at the metadata in the certificate and see that the other end claims to be A, and can examine the signature to see how much to trust that assertion; if the metadata is signed by an authority that B trusts (directly or indirectly) then B can trust that the other end has A's SSL identity. If that identity is the one that they were expecting (i.e., they wanted to talk to A: in practice, this is done by comparing the DNS name in the certificate with the name that they used when looking up the server address) then they can know that they have a secured communications channel: they're good to go.
B can't impersonate A with that information though: B doesn't get A's private key and so it would all fall apart at the first stage of verification. In order for some third party to impersonate B, they need to have (at least) two of:
The private key. The owner of the identity needs to take care to stop this from happening, but it is ultimately in their hands.
A trusted authority that makes false statements. There's occasional weaknesses here — a self-signed authority is never very trustworthy, a web of trust runs into problems because trust is an awkward thing to handle transitively, and some CAs are thoroughly unscrupulous and others too inclined to not exclude the scum — but mostly this works fairly well because most parties are keen to not cause problems, often for financial reasons.
A way to poison DNS so that the target believes a different server is really the one being impersonated. Without DNSsec this is somewhat easy unfortunately, but this particular problem is being reduced.
As to your other questions…
Why use hashing on the certificate if a part of it is already encrypted by the CA? Doesn't this mean that no one can mess around with a digital certificate (in high probability) anyway?
While keys are fairly long, certificates are longer (for one thing, they include the signers public key anyway, which is typically the same length the key being signed). Hashing is part of the general algorithm for signing documents anyway because nobody wants to be restricted to signing only very short things. Given that the algorithm is required, it makes sense to use it for this purpose.
If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.
If you have several servers serving the same DNS name (there's many ways to do this, one of the simplest being round-robin DNS serving) you can put the same identity on each of them. This slightly reduces security, but only very slightly; it's still one service that just happens to be implemented by multiple servers. In theory you could give each one a different identity (though with the same name) but I can't think of any good reason for actually doing it; it's more likely to worry people than the alternative.
Also note that it's possible to have a certificate for more than one service name at once. There are two mechanisms for doing this (adding alternate names to the certificate or using a wildcard in the name in the certificate) but CAs tend to charge quite a lot for signing certificates with them in.
My question is can't "B" just take this certificate, thus stealing the identity of "A" - which will allow them to authenticate as "A" to "C"
There's also a private part of the certificate that does not get transmitted (the private key). Without the private key, B cannot authenticate as A. Similarly, I know your StackOverflow username, but that doens't let me log in as you.
Why use hashing on the certificate if a part of it is already encrypted by the CA?
By doing it this way, anyone can verify that it was the CA who produced the hash, and not someone else. This proves that the certificate was produced by the CA, and thus, the "validation etc." was performed.
If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.
It depends on the particular case, but you will likely have identical certificates on each.
First question: You are correct about what you get back from the CA, but you are missing part of what you need before you submit your request to the CA. You need (1) a certificate request, and (2) the corresponding private key. You do not send the private key as part of the request; you keep it secret on your server. Your signed certificate includes a copy of the corresponding public key. Before any client will believe that B "owns" the certificate, B has to prove it by using the secret key to sign a challenge sent by the client. B cannot do that without A's private key.
Second question: Typical public-key cryptography operates on fixed-size data (e.g., 2048 bits) and is somewhat computationally expensive. So in order to digitally sign an arbitrary-size document, the document is hashed down to a fixed-size block which is then encrypted with the private key.
Third question: You can use a single certificate on multiple servers; you just need the corresponding private key on all servers. (And of course the DNS name used to reach the server must match the CN in the certificate, or the client will likely balk. But having one DNS name refer to multiple servers is a common and simple means of load-balancing.)
In general, yes, if the cert file gets stolen, nothing will stop someone from installing it on their server and suddenly assuming the stolen site's identity. However, unless the thief takes over control of the original site's DNS setup, any requests for the site's URL will still go to the original server, and the thief's server will stay idle.
It's the equivalent of building an exact duplicate of the Statue of Liberty in Antarctica with the expectation of stealing away New York's tourist revenue. Unless you start hacking every single tourist guide book and history textbook to replace "New York" with Antarctica, everyone'll still go to New York to see the real statue and the thief will just have a very big, green, complete idle icicle.
However, when you get a cert from a CA, the cert is password protected and cannot simply be installed in a webserver. Some places will remove the password so the webserver can restart itself without intervention. But a secure site will keep the password in place, which means that any server restarts will kill the site until someone gets to the admin console and enters the PW to decrypt the cert.
Question N°1
can't B just take this certificate [...] which will allow them to authenticate as A to C
This part of the a larger diagram deals with that question.
Mainly : if you only have the public key then you can not establish an SSL connection with any client because you need to exchange a secret key with them and that secret key has to be encrypted using your public key, which is why the client asks for it in the first time. The client is supposed to encrypt the shared secret key with your public key and you are supposed to decrypt it using your private key. Since you don't have the private key, you can't decrypt the secret exchange key, hence you can't establish any SSL communication with any client.
Question N°2
Why use hashing on the certificate if a part of it is already
encrypted by the CA?
This is also answered in the original diagram by the question "what's a signature ?". Basically, we're hashing the whole certificate to be sure that it hasn't been tampered with (data integrity), that nobody has changed anything in it, and that what you see is really what was delivered by the CA. The diagram shows how hasing makes that possible.
Question N°3
If I am stackoverflow and I have 3 servers [...] do I have to have a
different digital certificate for each of the 3 servers.
This is not necessarily always the case. Consider the situation where all three servers are on the same domain, then you only need one certificate, if each of them is on its own subdomain you can have one single wildcard certificate installed on all of them.
On the contrary, if you have one server that hosts multiple domains you would have one single multi-domain SSL certificate.
I also have some answers.
Q1) If B steals A's certificate and try to impersonate as A to C.
C will validate the IP address of B and find out that it does not belong to C. It will then abort the SSL connection. Of course, even if C sends an encrypted message, then only the Real A will be able to decrypt it.
Q2) A certificate is usually represented in plain-text using the common format X.509. All entries are readable by anyone. The hashing process is used to digitally sign a document. Digital signing a certificate makes the end user validate that the certificate has not been altered by anyone after it was created. Hashing and encrypting the content using the issuer's private key is done to create a digital signature.