I try to read the certificates from my PKI smart card with C#.
I read that the certificates are copied from the smart card into the certificate store on my computer when I insert my smart card into the card reader.
But when I check the number of the certificates in the different areas (My, AuthRoot, Root, ...) of my certificate store I get the same number, it does
not matter if the smart card is inserted or not.
Here is how I check the number of certificates on my store:
var myStore = new X509Store(StoreName.AuthRoot, StoreLocation.CurrentUser);
myStore.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);
var count = myStore.Certificates.Count;
So how can I access the cerfificate on my smart card to verify the private key?
Thanks and kind regards
Friedhelm Drecktrah
This depends on the card type. On a native card (one having a file system), each certificate is simply stored in a file and can be read using standard commands, most likely READ BINARY. To find out the file ID(s) you typically have to look into support information, like PKCS-11 or PKCS-15/ISO 7816-15 directory files your card provides. In case of several certificates you have to resolve for the purpose (typically also in the file).
Related
Let's say we receive a PDF document that is alredy signed.
We'd like to add a new signature field to the document and send it to the person that needs to sign it inside our environment.
We've seen that it's possible with AcrobatPro to directly sign the document, but it's not possible to just add the signature field to the document without signing it. We don't have AcrobatPro licenses for every user on the organization that have to sign external documents, so we're looking for a way to prepare the document for them, so they can sign it just within Acrobat Reader.
We are on a quite big organization (around 3000 ppl) and our ERP already manages everything related to signatures to our own documentation, but we are seeking for a solution to sign external documents that already have been externally signed while our provider evolves a solution inside the ERP.
First of all, a bit of background - the actual questions are at the bottom.
I'm currently working on a web-based app (sort of SaaS) which allows users to send forms to their own customers.
These forms are simple, small contracts for small jobs where their customers say "Yeah sure, I'll do this and here's my confirmation".
The sort of thing that is being "signed" does not require a fully qualified digital signature and an electronic signature will suffice.
While, in this case, a simple checkbox saying "Yeah, I'll do this" would legally be sufficient, I'm keen to implement it with a signature pad. To be honest, it's just for the factor of being seemingly more binding and, well, "neat".
The current workflow looks like this:
User's customer opens web-form (the party being asked to sign is the only person in the universe to know the direct link)
Ticks a few boxes and enters text
Clicks "Sign" which opens an HTML5 signature pad (mobile) or a simple input (PC) to type their name
Clicks "Accept"
A PDF is generated for download and stored on the server (along with timestamp, IP, and a couple of other bits of information)
As you can see, the agreement in its entirety constitutes a simple electronic signature - even without the bells and whistles.
What I would like to do
As with any simple electronic signature, it's easy for any party to say that a document may have been tampered with.
So what I did is properly sign the PDF according to the specifications (using tcpdf): that entailed first generating the PDF and then adding the signature to the /Sig dictionary, then generating a digest across all byte-ranges (excluding the signature), linking it up with a .crt file and voilá: the document is signed with the lovely benefit of the signature becoming invalid if even a single byte is changed.
Now to the questions:
Is it possible to benefit from the "tamper-validation" without using a certificate? Like I say, these are not supposed to be digital signatures but rather simple, electronic signatures. Still, I'd like to benefit from any post-signature changes being highlighted.
Alternatively, I could also simply use a proper certificate for the signing process. But this certificate would be mine rather than my users' or even my users' customers'. In that sense, would it do more harm than good? I.e. the certificate belongs to the wrong party and therefore becomes meaningless; I, rather than the signatory vouches; "The document was changed and re-signed after I signed"; etc.
Is it possible to benefit from the "tamper-validation" without using a certificate? Like I say, these are not supposed to be digital signatures but rather simple, electronic signatures. Still, I'd like to benefit from any post-signature changes being highlighted.
No, at least as long as you want to do this in an interoperable way.
You can of course invent your own security system, create a PDF viewer or at least plugins for the commonly used PDF viewers to support your system, and roll these programs out to your users.
But if you want existing Adobe Reader as-is to verify the signature, you've got to go the X509 PKI way.
Alternatively, I could also simply use a proper certificate for the signing process. But this certificate would be mine rather than my users' or even my users' customers'. In that sense, would it do more harm than good? I.e. the certificate belongs to the wrong party and therefore becomes meaningless; I, rather than the signatory vouches; "The document was changed and re-signed after I signed"; etc.
When using your own certificate for signing, don't forget to properly fill the reason field so it indicates that your signature is applied as a counter signature to guarantee validatability.
With that in place I don't see your signature doing any harm.
The question is how much good it does, though.
Obviously the user still can claim that he signed something different... because he did! He signed the web form, not the PDF. Thus, you might have to provide proof that the PDF reflects exactly what the web form showed anyways, that the user signed something equivalent.
If you want actual non-repudiation by the user, you need to make him sign personally in a manner that is commonly accepted to not allow tampering. In other words, your user needs to apply proper digital signatures himself. Everything else is open to claims of forgery.
You can use trusted time-stamp (defined in RFC3161) instead of signature created by the customer or by your server. Time-stamp protects document integrity and proves that your document existed before a particular time. Technically speaking it is a digital signature created by a trusted 3rd party.
I am currently working on a project that deals with sensitivity customer data, and we are being recommended to use Digital Signatures as appose to Electronic Signatures due to its new scale and the sensitive nature of the customers' data.
I personally don't know what the legal issues are with Digital Signatures, but I know that sometimes a Certificate Authority are needed?
This program is being written in C# visual studios if that matters, but I don't really know where to start with this process. I know it works like a public and private key encryption , a Public Key Infrastructure, but I have been informed that you must "buy" a certification from a Certificate authority. You could also create your own?
I was also informed that I need to make sure this would also allow documents created by our program to be legally binding in the USA. That certain laws and procedures are different in different countries so I need to make sure these are in order before I even start coding.
I'm sorry if this sounds more like a legal question then a coding question. My searches aren't helping and I can't start coding until I know what I can and can't do.
SSL encrypts the data channel. It can be broken by the NSA and perhaps others but it is considered quite hard to do so.
I certainly think it is a reasonable and appropriate level of data security for many uses, but that is merely my personal opinion.
Digital Signatures do not encrypt your data. Digital signatures sign your data, assuring you and the recipients that the data was not changed en route, and giving you confidence that you know who signed the data.
You can use a digital certificate purchased from a certificate authority to sign data. Or you can create a self-signed key for your organization and then use subordinate signer keys. We have many many customers who do this.
Documents signed with digital signatures are legally binding everywhere in the world. In some jurisdictions, for some purposes, you need a qualified digital signature. That means that the certificate was issued to the signer by a recognized national certificate authority.
I suggest that you are a ways from coding--you need to better understand your business requirements first.
With digital signatures, protecting the security of the signers' private keys is extremely important. These days, centralized hardware-hardened appliances are often used.
Here are some APIs which make it easy to digitally sign documents and data while managing the keys via an appliance.
Disclosure: I work for CoSign.
Immagine a web application that lets you digitally sign (with personal digital certificates pkcs12 released by trusted CAs) and timestamp PDF documents with a Java applet or Active X. This must obviously happen on the machine of the user because the private key of the certificate is stored locally.
So once the PDF is signed and timestamped it is uploaded on the server.
Does the uploaded file have the same features of the one created locally? Does it have sense to talk about "the original version of the file"?
I'm a bit confused on this.
Correction:
i mean digitally sign a document with the private key of a personal digital certificate (should be pkcs7, pkcs12) to ensure that it has really been signed by someone and not someone else.
If by "the original version of the file" you mean that you intend to "freeze" the document so that nobody can ever make changes to it again - that is neither possible nor the purpose of a digital signature. Anyone could simply "cut out" the a signature embedded within a document, nobody would notice.
Protecting a document from subsequent modification involves some kind of DRM mechanism. For example, "watermarking" involving steganography is used to protect photos so that noone should be able to claim ownership of a photo, even after having modified it. But the technology is not very advanced yet, most algorithms can be easily broken.
This implies that the notion of "the original version of the file" in let's say a legal dispute is something that the involved parties have to agree upon in consent. There's no way to prove origin without either consent or a trusted third party that will attest the integrity of a document, e.g. if they have an independent copy of the document.
Apart from that, uploading a file should not change its contents. The file will have the exact same properties than the local one including the signature that was added on the client side.
The signature will only attest authenticity and integrity of the document. If it is vital for your application to be able to tell that the signed document received is actually the one that was expected, then I'd advise you to do the following:
Create the PDF on the server
Create a hash of the document (same algorithm that will be used by the signature applet)
Send the PDF to the client
Let the client sign it and send it back
Compare the client's hash with the one previously computed on the server
Validate the signature
Validating the signature will ensure integrity and authenticity, comparing the hashes will guarantee you that the signed document you received on the server is indeed a signed version of the original document previously created.
Concerning timestamps using local clocks: they're worthless, it's very easy to cheat. What you actually should use there is RFC 3161-compliant cryptographically secured timestamps, issued by a trusted third party. Currently that's the only reliable way to include the notion of time in PDF signatures. There's also built-in support for this in Adobe Reader for example. As these services are generally not available for free, it would make sense to add such a timestamp on the server after receiving the signed document. They are added as an unsigned attribute to the CMS (Adobe still speaks of PKCS7) signature, so it won't break the signature and can safely be added after signature creation.
Okay, let's try to answer your question (as I understand it).
You have some software which uses some private key (and a clock) to add a signature to a file.
This signature is depending on the contents of the file, and thus makes sure that the signer knew (or could have known) the contents of the file at the time it signed it. (There are some ways to have "blind signatures", but I assume this is not the case here.)
Uploading the signed file anywhere does not change anything here.
About the timestamp: The key holder can put in any timestamp it wants - so this only helps if you want to prove knowledge of the document at some point in time against the key holder, not if you are the key holder and want to prove that you signed at some point in time and not earlier or later. (Also, are you sure his clock is not skewed?)
About whether this is legally relevant, you will have to ask your lawyer. It might depend on
the jurisdiction in which the signature happened, and the one in which you want the signed document to be valid
whether the owner of the key had a chance to actually read the document before signing
whether the owner of the key had actually a choice of signing or not.
If you use some applet or ActiveX control in the user's browser, I would not be totally sure that the last two points really hold.
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.