How to check that smart card is working on linux? - linux

I've a PKCS-11 supported smartcard? I just want to check that my the smartcard is working fine or not. How can check it on Ubuntu? Please guide me. what software I can use? how what steps should I follow?

It is important to understand that PKCS#11 standard just defines the C language API to access smartcards and other types of cryptographic hardware (or even software). It is usually hardware vendor who provides software library (.dll for windows, .so for unix etc.) that implements PKCS#11 API and is able to access the hardware (smartcard in your case). Your application usually loads PKCS#11 library and uses PKCS#11 API functions it provides.
In most cases it is the best to use PKCS#11 library provided by your smartcard vendor but there are also many independent software vendors such as A.E.T. or Aloaha who provide smartcard middleware (software package that usually contains PKCS#11 library) that can access a bunch of widely used smartcards. You can also take a look at OpenSC project which provides an open source PKCS#11 library that supports many popular smartcards and USB tokens.
Now let's get back to your questions:
Do I have a PKCS-11 supported smartcard?
You have to check whether there exists a library (open source or commercial) that implements PKCS#11 API and supports your smartcard. If you can find such a library then the answer is yes.
How can I check it on Ubuntu?
If you already have PKCS#11 library then you can install "opensc" package which provides command line application called "pkcs11-tool". You can use following command to list readers and cards accessible via your PKCS#11 library:
pkcs11-tool --module your_pkcs11_library.so --list-slots
If you want to use PKCS#11 library provided by OpenSC project then just replace "your_pkcs11_library.so" with "opensc-pkcs11.so".
What software I can use?
PKCS#11 is widely supported standard so this question is hard to answer. I guess you would like to use open source applications with your smartcard because you have mentioned Ubuntu so here is the short list of well known applications that support PKCS#11:
Mozilla Firefox - supports digital signature and client authentication
Mozilla Thunderbird - supports digital signing of e-mails
LibreOffice - supports digital signing of documents
TrueCrypt - supports disk encryption
OpenVPN - supports client authentication
OpenSSH - supports client authentication

To verify Ubuntu sees your smartcard reader and identity card:
Install libusb-1.0-0-dev pcsc-lite pcscd pcsc-tools
The following tools will be installed:
pcscd - systemctl status pcscd - sometimes the card reader crashes this daemon, so you may need to restart it.
opensc-explorer - it searches and displays smartcard readers attached
opensc-tool - Options will provide detailed information about your smartcard reader.
pcsc_scan - will show you smartcard reader and its status. It should show your identity card inserted, as well as when you take it out. If it displays waiting on reader - restart the pcscd service and try again.
The following link describes this more in detail and setting up firefox/chrome for certificates
https://cubiclenate.com/linux/applications/utilities/dod-cac-ubuntu-linuxmint/

Related

Intel SGX developer licensing and open-source software

Is it possible to obtaining a licensed developer certificate for signing security-reviewed, community-developed open source SGX software binary in production mode, and publish it on open source repository like apt or rpm?
I just asked Intel SGX team, they said only verified vendors are able to obtain a certificate and run in production mode. It just like Appleā€™s App Store, no open source code allowed, right?
Well, it's possible, but it's a quite complicated task,
You will need to register yourself or your organization as an ISV with Intel, which is not an easy task, i.e. one of the requisites for the Remote Attestation is Mutual TLS, therefore and in order to get it working you need a Certificate which must be publicly available on an URL you control, so trust can be established between Intel and your server.

Allow only signed applets to be installed on a JavaCard managed by GlobalPlatform 2.2.1

I'd like to provision a JavaCard so that it only allows the installation of applets that are signed by a certain key. I am not sure whether this signature is part of the cap file format. I can already install a cap file from an Android device via code taken from GlobalPlatformPro. The GlobalPlatformPro README (https://github.com/martinpaljak/GlobalPlatformPro/blob/master/README.md) mentions application signing. But I am not sure this is the way to accomplish what I need to do. I am not even sure this is possible at all.
How do I need to prepare a card to only allow installation of signed cap files?
How do I create such a cap file?
I can already lock a card with a certain key, and then this key is needed to install any cap file. But this would mean that I need to distribute the key with the cap files, so it can be installed. That is not an option as it would compromise the key.
You should read the Global Platform Specification, all information is given there.
Points to look out for that should match your requirements:
Mandated DAP Verification
Delegated Management Tokens
You will still probably need to check that your Java Card supports the given feature(at least Tokens are optional for card manufacturers) and you will need a terminal software that supports this feature(which might be difficult, as it is not very commonly used).

Java Card: Can applets be installed by other applets?

In Java Card, is it generally possible for new applications to be installed from within the context of an existing application on the card, for example by sending the new code via an application-defined messaging format and then creating a new application instance using some card manager API?
Or is this only possible externally using the corresponding APDUs?
If this is something not covered by the Java Card and/or the GlobalPlatform specification, can it be done using vendor-specific methods?
Theoretically this could be possible for normal Java Cards, given that:
you can install an applet with the Security Domain privilege (support for this is optional);
the Security Domain has the option to perform INSTALL [for Load] (support for this is optional);
the applet can receive and alter the APDU buffer before the Security Domain functionality is invoked (using SecureChannel.processSecurity) - as processSecurity should itself retrieve the command data according to specifications this is more unlikely then you might first think;
the applet has been given access to the keys to recalculate the MAC (these are keys are kept hidden from the Applet itself), assuming that the card is in GP_SECURE mode.
In this case you could convert your own APDU's into specific APDU's that comply with the GP specifications and simply call SecureChannel.processSecurity to get them processed.
Practically I don't think above will ever be the case, but you never know. You'd explicitly go around the security protocols defined for the card implementation, so I'm pretty sure you'd be asked very explicit questions by anybody auditing the solution.
Now if you just want to install applets through your own security domain then this is explicitly covered by Global Platform. You'd just check the manuals of the product if security domains and INSTALL [for Load] is supported and you're good to go.
As vojta has already indicated, there is no API for handing over INSTALL [for Load] commands, so programmatically you'd be stuck.
An incredibly stupid way to do it would be to program your own VM and install it as an applet. Probably not practical in 99.999% of the cases. It would still only be reachable as the VM itself of course, it would not be given its own Application ID (AID) by the card.
No, it is not possible.
You cannot send APDUs from your applet to Card Manager applet, which is what you need to install a new applet. Card Manager also doesn't provide any Shareable interface for this task (usually).
The only way is to send APDUs via the terminal, but it is not what you probably want. This way would be easy: your applet would need to hold the complete binary of the new installed applet and keys of the Card Manager.
However!
You can install an applet by another applet on SIM card using so called proactive commands, see this SO answer. Provided the device allows it, you can send PERFORM CARD APDU command from the first SIM slot to the second SIM slot and install a new applet this way. Then you could use this new applet on SIM2 to install another applet back on SIM1.
Moreover, you could send OTA commands using proactive commands and install a new applet instance remotely. I tried this a few years ago with a very simple pair of applets and a test SIM card and it worked.
Theoretically, it might be possible to implement a Java Card applet which will spread itself over the mobile network provided you have all the necessary keys. However, this is closely related to the Java Card quine, which is not solved as far as I know.

OpenSC API documentation, tutorial

In last couple months while learning to develop Java Card applets I managed to develop ISO 7816 compatible file system applet. I successfully implemented most of the standardized APDU commands from 7816-4, -8, -9 standards (I used other available functional descriptions and standards like OpenPGP applet, IAS ECC, MUSCLE, CoolKey etc. to help me understand former standards).
Now I am trying to develop PKCS#11 implementation for this my own applet. I am familiar with using OpenSC tools for already supported cards (opensc-tool, opensc-explorer, pkcs15-init, pkcs15-tool etc.). But I would like to develop driver for this applet for OpenSC.
I browsed information available on their project site on github and found some documentation on implementing custom driver for OpenSC (entersafe card example, and general suggestions for card driver implementation). Also I found that on gooze.eu there were available some tutorials on OpenSC, but this site is no longer available.
So my questions are:
Where can I find some more information on OpenSC API in order to understand available driver code and to manage to develop my own?
Any general overview of API, about OpenSC architecture, description of available functions (description on intended usage of structures and functions such as sc_format_apdu, sc_transpit_apdu, sc_card_operatins as an example etc.) to give me a jumpstart for understanding OpenSC source code and implementing a card driver.
Are there any man pages for OpenSC API (googling I was able to find some, but very incomplete and sporadic).
Any information would be very helpful.
Why don't you either use IsoApplet (that has both JavaCard applet and OpenSC driver) or if you want to develop your own, learn from its source code.
Also, if you have studied the standards and existing applets (and drivers) you should have enough domain knowledge to get an idea of what some of the API functions do. If not, keep your code somewhere in public and you can (hopefully) get support from the OpenSC developers via mailing list.

Develop programs for Arm trust zone

How can I develop applications that use Arm's trust zone? Specifically, I want to develop a program that can save sensitive data in the secure world.
Should this program run in the normal world or the secure world? I know there are trustlets in the secure world, do I need to develop trustlets? Are there SDK or API
that I can use to directly interact with an existing secure world os or do I need to compile and install my own secure os?
Any advice will be greatly appreciated.
Thank you!
There are two extremes. These are documented in the Software overview chapter of ARMs Security Technology: Building a Secure System using TrustZone Technology.
APIs
At the one end of the spectrum, there is only a set of APIs which can be called from the normal world. This is detailed in the SMC calls for Linux. For instance, if the device contains a public-private key, an API call could sign data. The normal world would never have access to the private key, but anyone can verify that the device is original by verifying the signature. So the normal world is free to forward this request over any communications interface. This maybe part of authenticating a device.
Co-operative OSs
In this mode, there is a full blown OS in both the secure and normal world (called TEE and REE elsewhere). The OSs must co-operate with interrupts and scheduling. They may also use SMC calls, lock free algorithms and semaphores along with shared memory.
ARM recommends using the FIQ for the secure world and to leave the IRQ for the normal world. Specifically, there are settings to stop the normal world from masking the FIQ ever. All of these issue rely on the type of IPC, scheduling, interrupt response, etc that the system needs.
The simplest Secure scheduler would always pre-empt the normal world. Only the idle task would yield the CPU to the normal world. A more flexible solution would have the schedulers co-operate so that both worlds can have higher and lower priority tasks.
The better way is install a REE OS and a TEE OS in one device. When a program wants to do some sensitive things, the device will change to TEE OS, so you can deal with sensitive date securely. When you have done with sensitvie date, device will change to REE OS.
But implementing two OS switch on a device is a tough work.
Operating Systems such as MobiCore already exist and have been deployed on mass market devices such as Samsung Galaxy S3.
MobiCore is an OS that runs alongside Android, so trustlets (= MobiCore apps) can communicate with Android apps via a set of system calls to the MobiCore driver, which is the part of the Android OS in charge of communicating with the trusted execution enviromnent.
If you are looking to develop trustlets for MobiCore as explained above, you must become a MobiCore developer, which you could theoretically do by signing up as a developer for MobiCore's Trustonic venture.
If you wish to use ARM's TrustZone technology on your own device / dev board with an open-source secure OS, perhaps you can use OpenVirtualization's SierraTEE, which seems to be compiled for Xilinx Zynq-7000 AP SOC and also compatible with Android as the rich OS.
You can use OPTEE(Open Sourec Portable Trusted Execution environment) OS. If you are looking for trusted execution environment application examples, which are also know Trusted Applications(TA), then you can check this optee trusted applications examples repository and this TA using OP-TEE and Comcast Crypto API.
Optee os provides following APIs for writing Trusted Applications:
Secure Storage APIs for secure storage
Cryptographic Operations APIs for encryptiion, decryption of secure credentials and data
Secure Element API which help in hosting applications or applets on tamper-resistant platform
Time APIs
Arithmetical APIs
For client side or normal world optee provides:
Tee client side Apis
You can refer documentation here.

Resources