How to make a DSC USB Token with Pkcs12 certificate? - usb

Each user of our system uses an X509 certificate to sign documents or approve documents.
We issue certificates by ourselves and send them to users in form of a PKCS12 file. It works perfectly so far.
Now, we want to distribute our certificates in a USB Token like other Certificate Authorities do.
Can we make tokens by ourselves using .NET code? If not, which software is used for making such USB tokens?

USB Tokens are SmartCard in USB Drive with USB Connector fused into it. (Instead of Smartcard reader and USB Cable...!)
USB Tokens are cypto capable devices which stores user's private keys securely and public keys and Certificates may also be stored in it (but has limited storage space)
Any Government approved Certifying Authority or Self (Internal) Certifying Authority can enroll and issue certificates in USB Token.
Suggest you to buy any FIPS Certified USB Tokens or Smartcard available in your market.
Please refer to my posts about USB Token and APIs available for Certifying Authority:
https://security.stackexchange.com/a/252698/206413
https://stackoverflow.com/a/68556286/9659885
API available for Developers:
https://stackoverflow.com/a/63173083/9659885

I've evaluated a solution called EIDVirtual to create a smartcard from a regular USB. It's from mysmartlogon.com.
I works at my development environment. However I'm not sure is it straightforward for the end users or not. And the cost is needed to clarify as well. If each end user PC requires a license, then it is not feasible at all.

Related

How to implement AATL/EUTL signing certs delivered on secure USB token in a hosted VM environment

We are generating document PDF's as part of our server application workflow. We need to be able to sign these documents to prove they are from us and have not been tampered with. We currently do this using a self-signed cert and using syncfusion's PDF module (excellent sw btw!). The problem is (of course) that the self-signed cert is not in the CA trust chain so although the document is secured, it doesnt automatically validate that its from us.
I have been researching where to purchase AATL certified certificates from and have found several vendors (Identrust being one of the more affordable options). However, they all share the same delivery method which is they ship it to you on a secure USB or similar token. What I dont understand then is how to use this token with our hosted VM. Does anyone have any experience in using these types of token ie. are we simply able to export the private key from the token onto the server?
Thanks
You cannot use the tokens in this scenario.
The certificate issuer should provide you with a web-based API that you integrate in your signing process. Usually you send the document hash and get back the signature, but the actual flow and ins/outs depends on the certificate provider.
Then the PDF library you use should let you embed in the PDF file the externally computed signature.

Self signed certificate or CA certificate for IoT device

I can't understand which is the real benefit of using a CA certificate when it comes to secure communications between servers and IoT devices.
I'm working at an IoT device that uses Ubuntu as OS and I was planning to use CA certificate. But what happen if my users are not updating their devices firmware?
now that certificates expires after 1 year and considering that some users are not updating their IoT devices for a long time... the risk I'll run into is that those devices could not be updated after the cert expires since they can't communicate with my servers.
With a self signed cert I can set an expiration of 45 years and anyway I'll be to authority and I can revoke or decide when it is time to release a new cert or even cross signing certificate.
I'm obviously talking only about the communication between the device and servers... the rest api for users will use a default CA cert.
Another option that I'm considering is to use a CA cert for device and servers communication but also adding a self signed certificate that I can use as backup in case the the main certificate expires and the device needs to download new software (that will contain the new certificate) is this a viable solution?
Should I handle certificates in this way?! or maybe should I just use the OS root store and ensure that it is updated somehow? (in this case ... how?... the only way is to release an update of the device firmare I suppose)
Certificates are used for authentication and encryption. See https://www.ssl.com/faqs/what-is-a-certificate-authority/
If you want to make sure that, data you are receiving is coming from authenticated devices then you will use certificates.
You can use certificates to encrypt each and every request. But it will be heavy on resources. Or you use certificates to for authentication and return an JWT token for further request. (This is how service account works in cloud.)
Manual certificate management will become complicated in no time.
Service account is a common way to authenticate apps/ devices. Keycloak is an open source option to support service accounts.
You should keep device updation separate from authentication. Device updation may or may not happen on authenticated device. And waiting for certificate expiration to update the device sounds strange.

Obtaining an AATL certificate to use in my cloud-based service

I'm looking to obtain an certificate from an AATL authority to use in iText to perform tamper-proofing signatures to PDF documents as part of a cloud application that I'm working on.
As best as I'm able to determine, AATL certificates can be delivered as USB HSMs to customers after a standard Adobe AATL verification process. Unfortunately, this restricts the usage to devices I have physical access to, which obviously isn't feasible for a cloud application.
I've been trying to research what my best options are on this front, but haven't been able to find any clear guidance on best practices or impartial sources for knowledge. I've come up with two possible ideas to illustrate in slightly more concrete terms what I am looking for.
Obviously any answer that results in the same outcome of either of these ideas is more than welcome as well!
1st Idea
Is there any way for me to obtain an AATL certificate by generating a CSR from Azure Key Vault, or Azure HSM (Gemalto) and having an AATL provider issue their response such that the certificate is loaded into the Azure's standards compliant store?
By doing this, my hope would be that I could then code my Application using the Azure Key Vault APIs or the Gemalto HSM to perform signatures.
2nd Idea
If a USB HSM is my best option, is it possible to derive another certificate from my USB HSM and then load that into Azure Key vault? Will a key derived from one issued to my company by an AATL authority still pass Acrobat (and any other) authenticity checks? Or will any certificate with intermediaries between it and the AATL authority fail?
I've been digging into this since I have a very similar requirement at the moment. YES it is possible to store an AATL Document Signing certificate in Azure KeyVault because it is a FIPS 140-2 level 2 compliant HSM. You do not need the dedicated HSM although it is also supported (Azure dedicated HSM is FIPS 140-2 level 3 compliant).
As for the process, you are correct that you would need to issue a CSR from KeyVault directly. If your certificate is delivered on a USB HSM, you will not be able to transfer it to Azure KeyVault since it will be locked to the HSM.
I do not want to list any certificate providers in this answer but I was easily able to find at least 4 that supported my use-case with a quick Google search. I'm currently in the process of getting quotes from each of these vendors.

Device authentication using self signed certificate

I am looking for device authentication where
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
Each device will have a unique certificate that cannot be transferred to other devices.
A device certificate can be revoked anytime.
To achieve the above, I am planning to have another Service which would issue certificate to devices which is approved to use my service. I will issue the certificate via email to the user where he will install it manually. My users will use browser to access my service.
But I am not sure how would I achieve points 2 and 3.
Can you please guide as to how to achieve this using a self signed certificate?
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
You can use a SSL channel with client authentication or adding a digital signature to your messages
Each device will have a unique certificate that cannot be transferred to other devices.
it is not possible to ensure this using software certificates. If you distribute them by email, the user could install them in several devices.
You could use a hardware token (nfc/bluetooth) or preinstall the certificate in the Android/iOS KeyChain so it would not be extractable. but this complicates the distribution very much.
A device certificate can be revoked anytime.
Check revocation at server side before accepting a request from a client. There are standard protocols to do this ( OCSP, CRL), or use a custom mechanism since you issue them yourself

How do smart cards work for client certificate authentication?

I am trying to understand how client certificate authentication works with smart cards.
I've read about configuring Apache to authenticate users with a certificate. There are a lot of tutorials online, like APACHE web server and SSL authentication from LinuxConfig.
As far as I understand, once a certificate has been imported, anyone who can access the computer can launch the browser and use it. Thus, in the scenario of several users sharing the same account (or of an attacker having physical access to the computer and being able to log in), the user cannot be authenticated unequivocally. To avoid such a problem, when an account is shared, I could try not to store certificates in the browser.
Nowadays there are several USB tokens that can have certificates inside, which can be used to perform client certificate authentication to websites. Here are my questions about such devices:
By importing the certificate as a physical device, will the browser let me use the certificate as I imported it?
What happens if the certificate has a PIN? Does the browser ask for the PIN every time it is launched?
Can I be sure that the certificate cannot be extracted from the token/smart card reader? Therefore, unless the token is stolen, can I be sure that the certificate cannot be cloned?
by importing the certificate as a physical device, will the browser
let me use the certificate as I imported it?
Yes. However you may recognize a higher delay when using a hardware token compared to a software token (e.g. for a smartcard 2-3 seconds).
what happens if the certificate has a pin? Does the browser ask for
the pin every time it is launched?
by default e.g. Firefox only tries to access the client certificates if you connect to a web-page that has HTTPS client auth enabled. Then the PIN will be requested.
Usually the PIN is then no longer needed as long as the token is not removed but that behavior may differ depending on the used PKCS#11 module (the software that connects Firefox with the token).
can I be sure that the certificate cannot be extracted frmo the
token/smart card reader? Therefore, unless the token is stolen, can I
be sure that the certificate cannot be cloned?
Then depends on the token. Some may have an API for extracting the private key but usually you can only use or delete private key + certificate from the token.