I am trying to write my own CSP. I am trying to do this by implementing a dll file, but I am not sure if I am on right way.
I found something like this:
Cryptographic Service Provider Developer's Toolkit (CSPDK)
there are samples with CSP API
CPAcquireContext
CPGenKey
... etc.
(it looks for me like an old api or api for winCE)
And here comes my question, which functions should I implement to provide new CSP for windows 7 and XP.
Is my plan good? - should I implement simple DLL and put her reference in register?
Or am i missing something?
You might be missing CNG which is a (long term) replacement for the MS Crypto API. You can create modules for that as well. Unfortunately it is only available since Vista. Windows XP is too old (and you should probably not be producing new applications for XP anyway).
Your HSM vendor will have their CSP written for you. You will get this csp when you install their driver. All you will be required is to access this CSP from your code.
To interface with your HSM vendor's CSP(check what they support), either you should use PKCS#11 or use the cryptoAPI CSP functions.
Related
I'm in a situation that I need to use AES-256, SHA1,2 and RSA, but these functions need to be loaded from an intrinsic windows dll file (something like cryptoAPI in advapi32.dll, which can be found in C:\Windows\system32).
I've found almost everything I need in advapi32.dll except RSA encryption. So,do you know any other crypto libraries from windows (XP2 should be supported)?
In the worst case, any free external crypto library in dll format is appreciated.
RSA encryption/decryption is supported by the CryptoAPI.
From http://en.wikipedia.org/wiki/Microsoft_CryptoAPI:
[...]It is a set of dynamically linked libraries that provides an abstraction layer which isolates programmers from the code used to encrypt the data.
So, advapi32.dll ≠ CryptoAPI. However, since it is an abstraction of the CryptoAPI functions, linking to that dll should expose whichever functionality you need, algorithm-agnostic.
To answer the question strictly, the CSP library file that handles RSA stuff is rsaenh.dll. However, I'm not sure why you should need to know that necessarily; like #SimonMourier (and I) stated, CryptoAPI handles linking to the appropriate CSP. Calling the appropriate functions from advapi32.dll should allow the use of a variety of algorithms, including RSA.
If you're really that averse to using the built-in Windows stuff then there's always Crypto++. It supports being compiled as a DLL afaik. http://www.cryptopp.com/
Without using .Net or a 3rd party component, I've found no reasonable solution for RSA in windows. So, about .Net, please see klugerama's last comment. About 3rd party component, I've found a great library for VB6 user, which will works in Windows XP without the installation of .NetFramework 2.0+. It's called VBCOrLib :
http://www.kellyethridge.com/vbcorlib/
Alternative solution for C++ users was Crypto++ as suggested by RaptorFactor.
Thanks for all your helps !
I need to find the product version of an installed application using the product code GUID. Is there a way to do this using a simple API call of some sort? I have found ways to do it using P/Invoke and the WindowsInstaller namespace, but I am trying to avoid using P/Invoke.
The Windows Installer exposes Win32 API functions (P/Invoke) as you have discovered. It also has COM automation interfaces that wrap these APIs but I'm sure you can guess is this is even less elegant. Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an MSI interop library that wraps it as managed code but I'm sure you can guess what it's doing under the covers: P/Invoke.
There are ways of getting it from the registry but this is not the official API and is less elegant IMO.
So to answer your question, you are already doing it in a very good and professional way.
If you want to get sneaky you can look through the registry to figure it out. When an MSI is installed windows creates a set of registry keys under:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
or
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
(depending on your machine/MSI bitness)
Under that registry location there should be a registry value named "ProductVersion". The trick is to know how to 'munge' a windows GUID (see http://www.vmwareinfo.com/2011/09/surgically-eliminating-windows.html).
I need your advices what to use - Layered Service Provider or just load mine DLL in all
process and hook necessary functions using, NCodeHook or EasyHook library.
This is needed for inspection of HTTP traffic.
P.S. This need to be done for commercial application
Thanks!
Before making a decision you need to consider the following:
Code hooking:
AV doesn't like code hooking, if you're using a library that has external DLLs, run a check with AV total before committing to it.
Make sure the library's license works for you, for example, for LGPL you won't be able to embed the library as static without becoming GPL yourself.
I heard people managed to hook Metro apps, it's something to investigate.
If you have another code hooking app, it may conflict.
LSP:
The default MS sample/installer is broken.
You may get something working on a VM or fresh install, but to get LSP working properly across all OS and browsers, will take 6-12 months.
Will not work with Metro apps.
In Komodia we use a combo of LSP/WFP for our SDK, knowing what I know now, if I'd go back 4 years, I'd use LSP all over again.
Good luck.
Using Easyhook will be a nice way to do it check the following http://www.sghaida.com/easyhook-for-systemcall-hooking/
I've been asked to redesign our build/sign/release processes. I'm pretty happy with Windows stuff and I've identified several networked-HSM products that will do what we need. They basically integrate directly with CryptoAPI so the people doing the signing can just use signtool.exe as normal.
We currently have a separate Mac team who do their own build/sign/release. This is all working fine on a couple of Mac Minis in one of our DCs. I'd like to protect our Mac software keys as well and so I'm trying to find out how to integrate a networked-HSM into our Mac signing process.
I can't find any good information about this anywhere! So I'm hoping someone in here has done this already and can lessen my pain.
The actual questions are;
1) Can I use a HSM with the standard Mac code-signing tools?
2) Can anyone recommend a vendor/product for the above?
3) Can anyone point me towards some good documentation on Mac code signing and the inner-workings of the Mac crypto infrastructure?
Cheers
BHB
I don't believe any of the major HSM vendors (nCipher, SafeNet, etc.) have any hooks into the Mac code signing tools, nor do I believe Apple exposes any. Your best bet would be to try and determine what the code signing mechanism looks like when performed by the Mac tools and then try and duplicate it yourself manually. However, off the top of my head, I don't recall seeing that the major vendors support OSX-based HSM clients out of the box. I know that SafeNet supports Java via a custom JCE provider. If there's a PKCS#11 interface you can hook into, then you may be able to leverage OpenSSL or another similar toolkit, but it will result in some work for you.
Our VB6 application uses a 3rd party control (PowerTCP from Dart) for SSL3 connectivity. However, this doesn't seem to work on Windows 7 - and I have not found any useful information on what I can do to make it work.
Is there a VB6.0 compatible control that will work on Win 7 for SSL3 communication?
Unfortunately, I can only suggest a workaround, not a solution: If you do not find a suitable ActiveX control for your VB6 application, you might consider migrating the communication part of your application to VB.NET.
This has the following advantages:
Calling .net code from VB6 is not hard.
The .net Framework has a built-in SSLStream class, which might already do what you want, so you're not dependent on a third-party component.
Since VB6 IDE support ended in April 2008, you will probably want to migrate your application to VB.NET sooner or later anyway. Therefore, migrating parts of your application now might be a better investment of your time than familiarizing yourself with a new third-party ActiveX control.
It has the following disadvantages:
One more layer in your application: Your VB6 code can call the .net code, but not vice-versa.
You need to familiarize yourself with the .net-COM interop stuff (it's not difficult, but it's something that needs to be done).
Your deployment process becomes more complicated, since you require the .net Framework to be installed on your customer's machines and you need to register your .net library as a COM component (so that your VB6 application can access it).
Dart still support the ActiveX control - why not ask them for help directly and post a question on their support forum?
Apologies in advance if you've already tried this.