Is it generally possible to access a shareable interface of an applet installed in a different Security Domain in a card compliant to both Java Card and Global Platform specifications?
If this is not possible, is there another way of invoking applications in another Security Domain, potentially by manually communicating via Secure Channels?
From the JavaCard Runtime Environment spec, Shareable Interfaces (6.2.4) :
Shareable interfaces are a feature in the Java Card API to enable applet interaction. A shareable interface defines a set of shared interface methods. These interface
methods can be invoked from one context even if the object implementing them is
owned by an applet in another context.
The applet firewall of the Java Card world divides between contexts(6.1.2), the ShareableInterfaceObject is spefically designed to enable interaction between contexts that would otherwise be forbidden.
The concept of Security Domains originates from the Global Platform specifications and is not present in the JavaCard specification. Searching the term in the JavaCard documentation will actually yield no results. As these things don't have anything in common, there should not be a problem with your setup.
Related
I am reading this AUTOSAR documents, and it says that the communication of the software components with each other and the communication of the SWCs with BSW is realized via RTE Layer, but I did not find any information about the implementation of the interactions between basic software modules with each other, for example, the interaction between ECU AL layer and MCAL Layer.
There are 3 types of interfaces according to AUTOSAR. They are : "autosar interface", "standardized autosar interface" and" standardized interface".
The "autosar interface" is used to define the ports for SWCs. Then there is "standardized autosar interface" type, which is used to define SERVICE ports for SWCs. These two types both are used for SWCs and both models the communication mechanism using ports, but the "standardized interface" do NOT use the same technique as "autosar interface".
I mean that probably the "standardized interface" contract do NOT use PORTS to define the communication between BSW modules and I want to know that if there are no ports for BswMs, then how do they communicate? Are the communication mechanisms modeled in those modules themselves?
1. Do the BSW Modules have ports?
2. Does RTE define the communication between MCAL Layer & ECU Abstraction layer?if not, then in which part of the code it should be implemented?
1.) Ports are the preferred way of interface definition on software component's level. The "standardized intefaces" are SwC ports that give access to underlying BsW module functionality. They are categorized as service-ports and their components are typically bound to an ECU.
Vendors exposing BSw module functionality to other SwC-s by their custom SwC is breaking the layered architecture and it is considered bad practice. (Thank you Uwe for pointing that out in the comments)
2.) On a module's level interfaces are header files with certain function declarations in them. Inter-BSwM communication is not RTE's task by design. Also, boot sequence is bottom up; it could happen RTE is not even booted yet for BSwM-s to use.
Think of ports as a logical feature. Based on their type you have some freedom in modelling them. When you generate the RTE these ports are realized (or in other words boil-down) to a certain solution: writing a buffer or as simple as a C function call. This abstraction even enables you to re-allocate your SwCs to another AUTOSAR ECU and the ports will still function.
You do not have this much freedom in BSwMs; their communicaton is more concrete, with C function calls. BSwMs can be optionally modelled in AUTOSAR: their interfaces as well as their internal behaviour. But unlike in SwC, such models are not having a direct effect on the implementation. They are rather for documenting, writing tests or compliance checks.
I have started to develop applets for smartcards using javacard.
When an applet is compiled it must be loaded to the javacard through a secure protocol defined in the Global Platform specification (https://globalplatform.org/wp-content/uploads/2018/05/GPC_CardSpecification_v2.3.1_PublicRelease_CC.pdf).
In particular, loading the applet on the card requires to know cryptographic keys that are used to setup a secure channel between the host computer and the smartcard. Blank cards are typically provided with default keys such as "404142434445464748494A4B4C4D4E4F". To 'lock' the card and ensure that it cannot be tampered, these keys must be changed to something known only by the issuer.
My question is the following:
What is the risks associated with issuing cards using the default test keys?
Here is a list of threats that I could think of:
A user can remove the applet and reuse the card for another purpose
A malicious software could uninstall the applet (denial of service)
A malicious software could remove the applet and install a backdoored one instead to steal user credentials in future usage.
Are there any other threats? In particular, is it possible to recover sensitive data (e.g. cryptographic keys) stored in an applet already installed on the card?
I would like to understand the exact security implications of using a smartcard with the default keys for the secure channel.
The data of the applet should be protected by the "firewall" that is implemented according to the Java Card Runtime Specification (JCRE), chapter 6: "Applet Isolation and Object Sharing":
The Java Card technology-based firewall (Java Card firewall) provides protection
against the most frequently anticipated security concern: developer mistakes and
design oversights that might allow sensitive data to be “leaked” to another applet. An applet may be able to obtain an object reference from a publicly accessible location. However, if the object is owned by an applet protected by its own firewall, the requesting applet must satisfy certain access rules before it can use the reference to access the object.
The firewall also provides protection against incorrect code. If incorrect code is
loaded onto a card, the firewall still protects objects from being accessed by this code.
To do allow sharing the sharing class would have to implement the javacard.framework.Shareable interface (6.2.6 Shareable Interface Details).
Beware though that the attack surface is greatly enhanced if you allow untrusted applets to be run. The likeliness that the security constraints cannot be met will definitely increase. These keys are considered vital to Java Card security and the default keys should always be replaced. If you order larger quantities of cards it is usually possible to replace the default keys with customer specific ones.
Note that at the time of writing the site of Oracle is partly down and I cannot access the documentation. This text is taken from the 3.0.1 specifications that I had stored on my personal computer.
How can one define a customized security domain on a smart card? Suppose that I have a GSM sim card in my mobile (I don't know operator key set to modify my sim)! Am I correct if I want to install a customized security domain on the same sim card in order to have an independent island on the sim to manage few applets of mine (not the operator)?
What properties should a security domain have? Is that possible to write one or use any pre-written online? Is that possible to install it on sim card without knowing the key set?
First of all, Java Card is a programming language to write applets that run on smartcards with a Java Card RE/VM. Global Platform is a standard for installation and management of smartcard applications, that includes the concept of Security Domains. Many smartcards out there combine both (although that is not necessary) and I assume this is your usecase as well.
There are two types of security domains, the (highest,top-level) Issuer Security Domain and Supplementary Security Domains. Firstly, if you not know the keys of the Issuer Security Domain, you cannot add another Security Domain or any other applets. The ISD is always preinstalled and usually there is a SSD load package on the card, that can be used to install and instantiate a SSD. The Security Domain is just another applet with the Security Domain privilege, but it has the functionality to load/install/manage applets and interact with the JCRE/VM directly. Technically you might be able to add the Security Domain privilege to your self-written applet.
All the information can be found in the freely available Global Platform specification and its needed to read through the pages if you want to dig deeper.
Basically, i'm trying to figure out if you can add a software to run alongside an already installed POSs, that can also access the barcode scanner?
Does it depend on whom the POSs has been installed with?
Please help!
I'm pretty new in this area, but I know that UPOS has the concept of Sharable Devices, multiple apps can use the device in this case.
Some devices are sharable devices. An example is the keylock. A sharable device allows multiple Control instances to call its methods and access its properties. Also, it may deliver its events to multiple Controls. A sharable device may still limit access to some methods or properties to the Control that has claimed it, or it may deliver some events only to the Control that has claimed it.
https://www.omg.org/retail/unified-pos.htm
#Rachel McConnell,
It is certainly possible for two applications to use the barcode scanner if neither application holds an exclusive claim on the device when it is not actively using the hardware, however many POS applications assume they are the only application using the hardware.
If both applications are using Windows.Devices.PointofService, there is a negotiation process built into the platform that requires the application with an active claim to respond with a retain() to keep the claim if a second application requests a claim. If the first application does not respond with a retain() in a matter of seconds, the claim is revoked and given to the second application. I do not believe other UnifiedPOS implementations provide similar capabilities.
For more information, see: https://learn.microsoft.com/en-us/windows/uwp/devices-sensors/pos-basics-claim
Hope this helps
Terry Warwick, Microsoft
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.