I am new for developing CryptoAPI with signing certificate in VB. My old system uses emvtool.exe to sign the certificate with Luna CA3 and HSM. For example, get keys, format data and sign the certificate. I read all the files about CryptoAPI and CSR workflow. I need to redesign the format data and signing parts. I am totally lost on how to use CryptoAPI instead of emvtool.exe.
thanks for any help.
I'm not familiar with the CryptoAPI in Windows, however, I believe if you have the Luna driver installed on the machine, you most likely have a "Crypto Provider" listed in Windows for the HSM. This is useful in interfacing with the HSM when performing some Windows crypto operations. So I'd dig into the CryptoAPI and whenever there's mention of a parameter for the crypto provider, use the Luna's provider.
Related
I'm creating an application for a select group of people to use. But since it'll be free-ware I can't afford to buy a digital signature to authenticate the source as me. Do I have any other option? Are there any tools in windows I could take advantage of? Any free (third party) tools that I could use to increase the chances my app wont be flagged as potentially malicious? I understand that obviously these things aren't the easiest to come by, but I'd like something to at least say the applications not been tampered with.
Can you please advise me on any tools or methods I could use.
No, in the end these things are about trust, and unless you can get a key trusted at the location where they want to verify the binary, you cannot confer trust of the library.
Key trust is normally established using a certificate that was created for you. Buying a signature would only make sense if there is a separate party signing the code as a service.
Of course there are other ways to trust an application; e.g. you can distribute the source and allow builds of the application at a location that the user can trust. But that won't be as convenient as receiving a signed binary, if the system has been setup to mark those as trusted.
My company makes a measurement device that connects to the PC via USB and used to use the Windows in-box USB HID driver. I'm using a different driver now to control the device and I am in the process of signing these drivers for many Windows versions. The reason being we want our customers to be able to install our measurement software (which would pre-install these new drivers), plug in our measurement device, and have Windows trust and use our new driver in favor of the in-box USB HID driver. It would also have the added benefit of using this new driver each time the device is connected no matter what USB port is used or if the user connects a unit that has a different serial number in the descriptor.
I've read through and performed the steps outlined in the KMCS_Walkthrough written by Microsoft to perform Test Signing of this driver by creating a catalog file for Windows 7 x64 from the inf file and signing the catalog file with a self-signed certificate. Things seemed to work smoothly on a Windows 7 x64 machine when rebooted into Test Mode. What surprised me was that I was able to create an XP_x86 catalog file, sign it with my test certificate, import my test certificate into the Trusted Root store and get the driver behavior I wanted on a Windows XP machine. The default driver signing policy was set to the default (Warn - Prompt me each time to choose an action).
I'm surprised because all of the MSDN documentation I have been reading about signing drivers for public release for XP seems to have a strict stance on the drivers being WHQL certified in order for the drivers to be fully trusted as opposed to obtaining a code-signing certificate from a third party and using that to sign the driver. Is this not true? How could my self-signed drivers out-rank the in-box USB HID driver in Windows XP?
I think your experience is normal.
At my company, we have distributed USB drivers to Windows XP users and we never had to sign them to get them installed. We later starting signing them ourselves, but that did not really affect the Windows XP user experience.
Our drivers were usually INF-only or they used WinUSB, so that might be different from you if you are compiling binary drivers.
Without a WHQL signature, Windows XP users can still install your driver package as long at they click through this warning:
After the driver package is installed, in my experience there is nothing that prevents the kernel modules it contains from being loaded into the kernel. However, our users always had to go through the "Found New Hardware Wizard" whenever plugging a new device into their computer for the first time.
Perhaps your driver outranks the HID driver because you picked a more specific identifier string (i.e. one with a vendor ID and product ID in it).
For more information I recommend reading my article: Practical Windows Code and Driver Signing.
After A LOT more trial, error, and research, I've finally come to a conclusion.
The key in my initial question was that I was using a self-signed certificate. I generated the self-signed certificate in Windows using makcert and following the example in the KMCS_Walkthrough:
makecert -r -pe -ss PrivateStore -n CN=CompanyName MyCertificate.cer
The parameter which specifies what Enhanced Key Usages (EKUs) the certificate should be valid for (-eku) is not included. What I didn't know was that with this parameter missing, this creates a self-signed certificate with ALL EKUs. Most notably the EKU called "Windows System Component Verification (1.3.6.1.4.1.311.10.3.6)". This EKU is included in certificates for WHQL signing.
So, in fact, Windows XP was behaving appropriately. My driver was indeed WHQL signed, it was just a self-signed WHQL certificate that was used.
I need to sign my Adobe AIR application which is a native installer. Right now I just have a Windows version, but soon I'll be porting it to other OSes including mobile OS.
My query is whether I need to get a separate code signing certificate for each one or is one enough? Also does 32-bit and 64-bit matter?
Verisign have categorized certificates for Windows (.exe) and Adobe AIR (.air and .airi) separately. So which one should I obtain?
CAs selling code signing certificates always pretend that you need different certificates to sign different kinds of applications. This is basically a scam. Most of the time the certificates are exactly the same, only the file format might differ. Even if the file format isn't supported by your code signing tool, there are ways to convert between different formats. So basically it doesn't matter which certificate you buy.
If you package your AIR app with a captive runtime, you can simply use a self-signed certificate with the adt tool. It's only important to sign the executable created with adt and your installer afterwards. If you create a native installer directly with adt, provide your certificate using the code signing options.
Under Windows, you should use Microsoft's signtool utility to sign the .exe file of your app and your installer if you want to package with a captive runtime. So I'd choose a code signing certificate for Windows. But as I said, it doesn't really matter (and there are cheaper options than Verisign).
Under Mac OS X ("Gatekeeper"), things are a little different. You can only use certificates issued by Apple. You have to enroll in the "Mac Developer Program" ($99 per year) to receive a code signing certificate for OS X. If you use a captive runtime, sign the application bundle created with adt using the codesign utility. If you create a .pkg installer, use the --sign option of the productbuild tool. There's a similar "iOS Developer Program" for iOS apps.
Under Linux, you don't sign packages with certificates issued by a CA. You simply sign them with a GPG key that you can create yourself for free. You have to publish your public GPG key so your customers can make sure that your packages are valid, though.
For Android apps, you can simply use a self-signed certificate, AFAIK.
32-bit and 64-bit apps can be signed in exactly the same way. You don't need separate certificates. But adt will only create 32-bit apps anyway.
I created a test domain, a CA and I issued a certificate with that CA. I also have fully functional CSP. For logging on, Windows are offering smart card as logon option. However, when I insert the card, after a few seconds of interaction with the card I receive the message "no valid certificates found". I did my homework by reading tons of MS documentation and generally whatever Google offered. Since I have no more options I'm trying here.
Added after posting: The certificate was created from the Smartcard Logon template.
Here are a few things I would check:
the authentication cert asserts the windows smartcard logon OID in the EKU.
the authenctication cert has a UPN in the subject alternative name (not stricly necessary for windows 7/server 2008).
the authentication cert key usage is digitial signature.
the domain controller has the certificate chain installed correctly.
How was the card issued?
* Follow-up *
How did the certificates make it on to the card? AFAIK, there is no card management built into Windows, so an external card management system is needed to load the certs on the card in whatever card applet you are using. Can you provide more specifics on the card you are trying to use?
* Follow-up *
You might find this link interesting; it's for PIV cards but the same ideas probably apply to your situation - the article describes a test lab setup for smart cards. In particular, check out which certs go in which trust stores.
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9427
You may find commercial software automating the binding process but no free ones. This way you won't have to check tons of support KB.
You can get a look at this demo (http://www.youtube.com/watch?v=OkMGXr-bls0) to see one of these tools in action.
I would like to do Symbian programming with features that require an application to be signed with more then the standard self signed cert. I don't want to pay mony for a cert since I don't know if I will get to a point of selling an application. Is there a way to grant capabilities such as read and write device data to my application for use on just my phone?
If you don't have a Publisher ID the only option for you by now is Open Signed Online.
Open Signed Online allows you to sign an application for installation onto a single device. Unfortunately you will get the signed application, not a certificate itself.
Aside from Open Signed Online, which is pretty hopeless when you want to debug on the device, the only options at the moment are to find someone with a publisher ID to create a developer certificate for you device via Open Signed Offline, or wait for Symbian to come up with another way to get you a developer certificate. They are already planning to make publisher IDs cheaper and easier for individuals to get (currently you need to be a registered company) and wider availability for developer certificates is also on the cards.