When I run pkcs11-tool I always need to specify a module:
pkcs11-tool --module=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -L
What is this module for and how pkcs11-tool use it? Which are the other possible modules I can use? What is the difference between them?
I tried to use another one ("/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so"), but I always get an empty slot, so I suppose there is a difference in the purpose of the modules ?
The modules are used as middleware to the actual device like smart cards, USB tokens and hardware security modules (HSMs) or even software emulations for PKCS#11.
You can think of it as a hardware driver mapping PKCS#11 to the concrete device, with some modules offering vendor-specific algorithms, login mechanisms etc.
Some known modules are listed here:
http://wiki.ncryptoki.com/Known-PKCS-11-modules.ashx
Using OpenSC, you already have support for a lot of different devices:
https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-(smart-cards-and-USB-tokens)
So given you stick to those devices listed there and don't use any special function not supported by OpenSC, you should use OpenSC.
Related
Is there any repository where one can find standard applets introduced in Global Platform or ETSI or other standards (e.g. Security Domain, Contactless Registry Service, etc.) ???
Unfortunately not. Usually these applets (Security Domains, USIM, RAM/RFM OTA, ...) require some native integration in the operating system because the standard JavaCard API is not sufficient here, e.g. think of the necessary Milenage or TUAK algorithm needed for the network authentication of an USIM - there is no JavaCard cryptographic support for this (OK, Milenage could leverage the AES as primitive).
Hence all the implementations are custom implementations by the vendors. Because SIMs/eUICCs are also in control of a mobile network operator there is also no use case why this could be useful to an individual developer which can another reason why nothing is available as OS here.
I am interested in writing a Vala program that will determine the present operating system and act accordingly (exactly how it will act I have not decided yet, but is not relevant to this question). So what I would like to know is how I might determine the present operating system (including the specific distribution in the case of Linux) in a Vala program at runtime.
Unless you are writing system level code (like package manager or OS configuration code), you shouldn't. A much better alternative is to use a library that already abstracts the distribution specifics for you.
If you absolutely have to there are two main ways to do it:
At build time
Here your build system should be responsible to detect the OS / distribution and either pass a define to the compiler (like -DDISTRO_UBUNTU) or write a config.vala file (possibly from a template config.vala.in with replacements, e.g. autotools has the AC_CONFIG_FILES facility to do this).
At runtime
Here your tool does the detection itself when it's running.
Which fits your application better is a design choice.
As to how to do it there are several things you can check:
uname -a (or other parameters, see man uname) will give you the kernel that is currently running.
lsb_release -a (not available on every distro, sometimes an optional package which you might have a package dependency to) will give you information on what distro and what distro version you are running on.
On Debian/Ubuntu derivates there is a file called /etc/debian_version which gives an indication of what release is currently installed. That information is not totally accurate though.
Some people are trying to read /etc/issue, but that is dangerous, since that file could be modified by the admin / the user.
You could ask the user which OS she is running.
There are also some os info libraries that you could use.
You might use the uname(2) syscall (how to do that in Vala is left as an exercise to the user), or read /proc/version (see proc(5)), or read /etc/issues or follow Linux Standard Base conventions (e.g.popen the output of lsb_release -a).
But as Jens Mühlenhoff answered, you should not do that, and avoid writing code depending on some particular distribution.
And some users might want to fake or hide that information (think of someone having some "Linux From Scratch" system).
Has anyone used CKO_VENDOR_DEFINED to create a key or a data object?
There is hardly any documentation (including the mother load from Oasis) about how to do it, or which attributes are applicable/not-applicable.
Unfortunately, but hopefully understandably, I can not describe exactly what I am trying to do.
But the gist of it is that I need to be able to have a bit more attribute<=>mechanism flexibility with our kind of keys and the ability to modify a key on the token.
I'd really appreciate any pointers or help.
You can take a look at OpenPGP extension to PKCS #11 where CKC_OPENPGP is defined as:
#define CKC_OPENPGP (CKC_VENDOR_DEFINED|0x00504750)
I've seen also commercial implementations introducing CK*_VENDOR_DEFINED extensions this way.
(AFAIK) vendor defined object types must be implemented inside the HSM unit firmware (in theory, the host-side cryptoki library could introduce some additional "virtual" object types, but this probably would not make any sense as the overall security model would stay the same -- because the host-side cryptoki code runs in an untrusted execution environment).
If you need more control than provided by the vanilla PKCS#11 you have some choices:
Use existing vendor extensions -- some vendors add their own extensions designed to solve common use-cases. Read your documentation or contact your vendor directly.
Implement a custom firmware -- some products allow the end-user to run a custom code inside the HSM device. You can implement your model this way.
SafeNet ProtectServer:
SafeNet ProtectServer HSMs offer a unique level of flexibility for
application developers to create their own firmware and execute it
within the secure confines of the HSM. Known as functionality modules,
the toolkits provide a comprehensive facility to develop and deploy
custom firmware.
Thales nShield:
Most nShield HSMs also support the unique ability to host critical
applications within the hardened security boundary, so you can
establish tamper-resistant business processes in addition to
protecting cryptographic operations.
Utimaco CryptoServer:
The CryptoServer Software Development Kit (SDK) is the professional
development environment for all Utimaco Hardware Security Modules. It
enables integrators and end-users to create specific applications,
e.g. proprietary algorithms, custom key derivation procedures or
complex protocols that run in the tamper-proof environment of the
CryptoServer Hardware Security Module. As the SDK provides full access
to the Utimaco base firmware, custom firmware modules can be developed
in a very short time frame.
Use some other technology -- do not use HSMs at all and leverage some other secure device. Specifically smartcards might be a viable alternative as some of them can be programmed (at least Java Card or MULTOS ones). On the other hand the performance and range of supported algorithms is quite limited here (depends on your use-case).
I've built a set of tools I use in my day-to-day work and I would like to make them look a bit more "professional" in order to sell them to financial institutions.
At the moment these tools are written in Perl and are executed from a DOS command line, it's extremely efficient but it doesn't look very attractive.
So, I would like to add a user interface to it but I don't really know what to use for language knowning that :
A Perl CGI interface hosted on the web is not an option since the information to be given as input is quite sensitive.
It would be ideal to sell it as a package/executable.
I don't really like the Perl/Tk interface.
I'm ok with rewritting the application in another language but I would prefere to reuse the main modules in Perl since it's very powerful with regular expressions and lists/arrays.
What would you advise me to do ?
Thanks,
Lory
If you want a non-web-based GUI, and don't like Tk, there's also Wx, which is a wrapper for the wxWidgets GUI toolkit.
However, web applications nowadays can be really easy to create (using a modern framework). Take a Mojolicious application, for example: Mojolicious carries no dependencies other than Perl 5.12.x, and provides its own web server (Hypnotoad). You can start by generating a "Lite::App", which is a simple self-contained single-file application, and then grow it to a bigger distribution later on as the need arises. It even comes with tools to convert your application to a conveniently packaged distribution that can be installed as easily as any CPAN module.
So that leaves the issue of security. User authentication, IP whitelisting, local network only... there are many ways to make a web application "for internal use only" if that's what you need.
You might just throw together a web-application prototype, and once you determine customer interest in your product, invest the substantial time in writing it as a Windows GUI application.
Continuing on from DavidO's answer, because the current web microframeworks for Perl (I prefer Dancer over his suggestion of Mojolicious, but both are good and largely equivalent) contain their own bundled web mini-servers, they also allow for the app to easily run entirely on the local machine.
Since these mini-servers default to a non-standard port (usually 3000 or 5000) by default and you can easily set them to a different port, they can be isolated by firewalls relatively easily, ensuring that nobody can connect to them remotely. You can also, of course, include and IP address check in the app and have it reject any requests that don't originate from localhost.
My guess is that the target system will be Windows. Use a RAD (Rapid Application Development) platform to develop a GUI. Examples for such a platform are Delphi or .NET with C# or VB. For bundling the Perl part, consider using a tool called perl2exe.
It doesn't sound like your scripts should require a web server. Also, consider the installation hassle. Only guessing as you're not giving much information about what your scripts are doing.
I am using the Cava packager to deploy my Perl-written tools. You can even generate an installer executable with just some mouse-clicks. It works pretty well with strawberry Perl and wxPerl on Windows.
I am fairly new .. I want to ask
If i can get the installed system drivers of any device/interface card in my Pc and use it in my own applications.
If i can then .. Can anyone tell me if i can use the sematic s7 installed MPI drivers for communication with the Siemens plc with my own application..
I want to use this with c#.net in windows environment
The first question needs more work: the drivers, once installed are already there. There is no concept of "getting" them. You can open a handle to installed drivers to perform various operations, if you know how, and the means to do so differs greatly between different types of drivers.
As for the second question: unless you either have source code or documentation of the driver in question, I doubt it would be possible. Of course, the simplest alternative is to obtain a library from the vendor to access the PLC from an application. The library will hide all the tricky parts of using the driver.