Are there any OpenSSL engines that do everything in software and store the secret keys in a file (possibly even in plaintext)?
Perhaps this can somehow be achieved with OpenSSL alone?
The purpose of this is to test whether a piece of software interfaces correctly with the engine API, without having any hardware.
It is assumed that at a later point in time, when an HSM is acquired - it would work with the software right away (provided that the HSM vendor offers an OpenSSL engine).
I am not sure whether pure software implementation of OpenSSL engine exists but you could try engine_pkcs11 with SoftHSM.
Related
I'm currently working on a prototype. I need RSA Encryption at the Linux Kernel level,although from my research, it seems that the Linux Kernel only supports signature verification. When I look through the code in rsa.c and rsa_helper.c, it seems that there is a rsa global struct that is set to static that has function pointers with variable names: encrypt and decrypt.
Also, there is not a lot of documentation on the asymmetric API. The tcrypto.c does not even test any of the asymmetric crypto API. This seems to be a huge limitation. I am aware that asymmetric encryption is not as fast as symmetric encryption, but I need it for my prototype.
Hopefully,I will not need to roll my own RSA encryption/decryption routines, because this would be a major set back.
Yes, the Linux Kernel supports RSA Encryption/Decryption.
Thanks to some comments I decided to dig a little bit deeper into the Kernel Source. This page is sort of helpful. It unfortunately doesn't require any code samples.
If you would like some code samples, then you can take a look at testmgr.c under the crypto directory. It contains a comprehensive list of supported algorithms in the code.
We are developing a JavaCard-based security sensitive application. Our goal is to allow client code communicating with a GlobaPlatform 2.2+ based JavaCard applet to convince itself that it's actually talking to a specific (and verifiable) version of the JavaCard applet it needs to talk to. In other words, we are looking for a "platform integrity" mechanism to be sure there's no possibility that the JavaCard applet code was substituted/modified by "insiders" (e.g. even us who developed the applet).
At first we were hoping to use an Installation Receipt mechanism as described in the GP specification, but we were advised that this doesn't apply in that case.
So is there a way for client code to query the card about the authenticity (e.g. a simple hash) of the applet codebase (i.e. the installed .cap file) without having to query and trust the JavaCard applet itself?
I wrote a simple cross-platform utility to verify GPG signatures using the gpgme. However gpgme doesn't work very well on windows and on other platforms (e.g. osx) it requires GnuPG command line utilities installed which is a pretty heavy dependency. I looked into other openpgp libraries as well such as netgpg but these are even less portable (it really has to build with mingw-w64).
Would it be possible to implement a standalone tool to verify GPG signature using only standard libraries like openssl and zlib? From what I understand openpgp consists of standard ciphers and hash functions. What is the part that makes this so difficult that there are no good C libraries out there to do this?
OpenSSL does not implement the OpenPGP format and is not compatible. Use an OpenPGP implementation like GnuPG, Bouncycastle (framework available for Java/C#) or others (OpenPGP.js for JavaScript, and there's a Go library).
While OpenPGP uses standard cryptographic digest and encryption algorithms, it has a different message format and especially uses its own CFB mode variant. You'd have to implement both a parser for the OpenPGP message format and get compatible with the OpenPGP CFB mode (if you want to support encryption), and finally pass the results to OpenSSL for the actual cryptography.
Finally, supporting the whole web of trust concept including the full OpenPGP specification is a broad task and has a variety of issues to consider ([1], [2], ...). In the unix world, people seem to be happy enough with GnuPG and GPGME, which are deeply tested and analyzed for even very advanced security issues (for example, this side channel attack). New implementations are most likely vulnerable to similar problems already solved for GnuPG.
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.
I have a low volume (<500 PDFs/year) application for automated digital-signing of PDF files using iText in Java on Linux.
I've got iText adding a digital signature to PDFs using my SSL certificate. Is this a valid method to prove the PDF was generated by my domain (e.g. server)? Can it be used somehow to get the green checkmarks showing "trust" in Adobe Reader?
If not, I should use a certificate intended for PDFs (e.g. not my SSL certificate), so that the little green checkmarks indicating "trust" appear naturally when the user opens the PDF document.
The book http://itextpdf.com/book/digitalsignatures does a great job introducing this topic to me (I have very little experience in this area).
The book talks about a SafeNet Luna device (an HSM), but's it is much too expensive. I only require a minimal solution, and the Luna has a lot of bells and whistles. The Luna PCIe device is less expensive, but I don't require any features other than providing a certificate I can use to sign. Also, the USB-based SafeNet iKey device seems only to be marketed to Windows devices. Has anyone got iKey working with Linux? Is it even possible? Do other companies offer USB based devices that work on Linux?
I'm looking for a minimal solution for serving automated digitally signed PDFs on a Linux box. I'm sure a lot of small businesses have similar needs. I'm just trying to tap into existing knowledge out there. How do people solve this problem?
The solutions I see for automating this process assume large corporations using Adobe Live Cycle, and priced accordingly (see for example: https://www.globalsign.com/pdf-signing/compare-pdf-signing.html). But small businesses need to automate things too.
Ideally someone would sell a certificate similar to the SSL certificates, but for PDF files. Is there such a thing?
Is hardware (of some sort) a requirement (seems so)? If hardware is a requirement, are there any minimal solutions out there (e.g. with limited functionality other than enabling digital signing)?
Hoping someone can help me see the forest from the trees. What's the conventional wisdom?
Regarding signing with your SSL certificate: in a future iText version, we make require that the key-usage of the certificate indicates that the certificate can be used for non-repudiation. For now, we make checking the key-usage the responsibility for the developer, but in a perfect world, you should only sign with certificates suited for non-repudiation, and your SSL certificate probably doesn't allow this.
Regarding the green check mark: unless you can ask the consumers of your PDFs to add the root certificate of your certificate to the list of trusted identities, you'll always need a public/private key stored on hardware to get a green check mark.
Regarding the price of an HSM / USB key. USB keys are much cheaper, but usually they are meant for manual use (usually they have a limit of signing only once every second). I think that GlobalSign has a flavor of keys that work on Linux. As for HSMs, one of our customers told us that he bought one from Utimaco because it was less expensive (but I don't know what budget he had or spent).
No price info, but maybe a good read for inspiration: http://www.opendnssec.org/wp-content/uploads/2011/01/A-Review-of-Hardware-Security-Modules-Fall-2010.pdf