I have a javacard and when I reset the card, all the applets on the card are cleared except one of them. and it is "Card manager applet" with "A0000000030000" as its AID. I want to know is there any way to delete this applet?! or it is mandatory on the card and there is no way to delete it?
if it is possible to delete it, after deleting it, how we can work with the card? (installing another applet and so on)
thank you.
The card manager is the manager that handles the application management of the card. It also determines the card states. Normally you cannot remove the card manager, especially not through the card manager itself. If you can delete it, it should be through a proprietary API of the card manufacturer.
As a analogy: you are asking Windows or Linux to delete itself.
You can however put the card in TERMINATED state, after which it is effectively dead. You can even do this from an Applet, if it has the TERMINATE CARD privilege, which can be assigned during INSTALL for INSTALL when the Applet is instantiated. After this neither the Card Manager not the Applet will work though.
Related
I want to create a javacard applet which could not be installed more than once at the same time. It means if I instantiate applet once, It could not be possible to install another instance of that applet. However, if I delete the first instance, it should be possible to reinstall it.
If the package AID is always the same the installations should fail during the loading process automatically.
If the package and instance AIDs are using some pattern like an increasing last digit you could use JCSystem.lookupAID and try to iterate over the possible AIDs and fail if another instance is found.
If you are taking into account that the AIDs are flexible you are out of luck on standard smart cards, what you need then is a global kind of data unique for all applets. When using an UICC e.g you could create a file in the file system and if your applet is part of the MNO's security domain you can check this file for existence.
Maybe you also protect the installation process, e.g. by using a personalization process. After the installation a personalization server has to approve the applet. The applet could use some random token and if this is not known by the personalization server the applet will never unlock some features to make it useful. This approach should always work.
Building a firmware using EDK2, what is the programmatic way to provide a default boot order? I want the default option to be boot from SD card. I have an bootx64.efi image stored in the SD card.
Every time when I build the EDK2 image and flash it on the target, I need to enter boot maintenance manager option and add SD card as boot option and change the boot order.
I looked into the code and read the specifications of Boot manager. I understood that I need to modify Boot Order variable but I don't get how to add SD card option in the source code.
I am looking into the QemubootOrder.c file but I don't understand where I need to add the path to SD card .
Well, first of all, if your UEFI port considers that SD card a "removable media", which is should - it should automatically load it if it is placed in \EFI\BOOT\ on the FAT-formatted EFI System Partition.
BootOrder comes in if you want to be able to support multiple options. But BootOrder itself only consists of a list of the numerical part of the available Boot#### options, in order of preference.
You can learn more about these mechanisms from the UEFI Specification. Current version is 2.6, and the most relevant bit for this topic is section 3.1 Firmware Boot Manager.
I have 2 cardlets Java Card on the same smart card that I want to make communicate.
I could select an applet then send the corresponding APDU and then deselect it and select the other one and etc... I am wondering if it is possible to do it
more properly
with logical channels ? I mean with a method that could allow me to not select/deselect each applet for each APDU command ?
Thank you in advance :)
Yes it's possible.
You need a card that supports additional logical channels.In that case, you can select more than one applet simultaneously.(One applet per each channel) Fortunately current cards support some additional logical channels.
But remember that if you want to select (at least) two applets of a single package simultaneously, you must implement MultiSelectable interface in both applets (and also in all the other applets of that package).
If your applets are not from a single package, you don't need to implement this interface.
After that, you can open 2 logical channel using MANAGE CHANNELS command and select App1 in channel 0, and App2 in channel 1 (For example). For the next commands, you specify which channel (and therefore which applet) is the target of the incoming command using the low nibble in the CLA section of that APDU commands.
Note that SELECT APDU command is an alternative for MANAGE CHANNELS-Open command.(So you actually don't even need to use MANAGE CHANNELS command)
You should read more about: Applet Firewall, Sharable Objects and Inter-Applet Communication. These are standard Javacard features that are (also but not only) designed for this purpose.
I have to find whether Smart Card has a given certificate in it. For that I am first acquiring the HCRYPTPROV (handle to the CSP) using CryptAcquireContext and then using it to Open the system store (OpenSystemStore) and then enumerating the certificates.
It works perfectly on Windows XP. On Windows 7 it gives issue due to stale/old certs stored in store.
Windows stores/copies the certificates in its store from Smart Card. That means if I have two certificates Cert1 and Cert2 on Smart Card and I have used smart card to logon into windows. then Windows stores these certs in its stores, we can see that by going to IE->Internet Options->Contents->Certificates. Then if I remove the Cert2 from the Smart Card, then also Cert2 is shown in Windows Store and this thing is breaking my code.
So I need to enumerate the certs which are available only on the Smart Card not in the Windows store.
Assuming the HCRYPTPROV you acquire is for the smart card, use CryptGetProvParam with the PP_USER_CERTSTORE parameter:
Obtains the user certificate store for the smart card. This certificate store contains all of the user certificates that are stored on the smart card.
e.g.
HCERTSTORE hCertStore = NULL;
DWORD size = sizeof(hCertStore);
CryptGetProvParam(hProv, PP_USER_CERTSTORE, (PBYTE)&hCertStore, &size, 0);
You can then enumerate the smart card's certificates from the HCERTSTORE as with the system store.
The MSDN page states "Windows XP: This parameter is not supported." but it works fine on XP with the latest Service Pack.
The CNG equivalent is NCryptGetProperty with the NCRYPT_USER_CERTSTORE_PROPERTY parameter.
Let's say that I have an application that helps people "manage" a certain number of "items". Normally they'd have to manage information about these items on paper, but my application will let them do it on the phone.
I want to sell my application by the number of items it supports. For example, I might charge $10 for the version that has a limit of 20 items, and $15 for the version that lets you manage 40 items.
What's the best way to do this? Ideally I'd like to let users download the application for free as a sort of trial that only supports a very small number of items like 2 or 3, then they'd have to use in-app purchases or something to buy additional capacity.
I also need them to be able to "re-download" their license from the app store if they wipe their phone or it gets destroyed.
I also want people to be able to buy upgrades as they go along. So once they find they need to manage more than 20 items or whatever, I want them to be able to buy an upgrade for 40 without having to reinstall the app or something.
Installing extra application bundles for each license or license upgrade seems like a bad way to do things, though I'm sure I could have them all use the same bundle seed ID and have them insert license info into the keychain or something.
Anyway, ideas?
You could use in-app purchase to add extra “items” to the user’s list. That will survive a phone restore and you could support adding as many “items” as possible.
I think the best way is to manage this via some sort of subscription where the 'items' are stored on your server rather than the phone. Then you can control the number of them and use the app to access each item.
So, you run the app, it manages these 'items' and each item is stored on your backend database. Depending on their subscription, you can allow/deny attempts to add items.
Alternatively, I guess you could do a similar thing on the iPhone using the built in database but you'll still need a backend somewhere to keep control of the number of items they can manage, whether that's via some sort of certificate or whatever.