A key concept in security is "defence in depth”: multiple controls must be performed in sequence to guaranty Confidentiality, Integrity and Availability of sensitive assets.
Java Card products and associated security services are examples of such assets. They are a critical enabler in our day-to-day lives: to pay at a shop, make a phone call, cross a border with a passport or to provide trusted and genuine data to IoT clouds for AI processing. The deployment of Java Card applications relies on an established ecosystem of hundreds of companies and organizations, organized around security practices that guarantee this defence in depth. The three pillars of this deployment model are code verification, chain of trust and certification.
Java Security and verification
As with any Java-based Virtual Machine, a fundamental feature of the Java Card Virtual Machine is the security provided by bytecode verification. A verifier checks the structure of a Java Card Converted Applet (CAP) file - the file format for Java Card applications - and perform bytecode verification ensuring type safety. Code verification is always a mandatory step. It must be performed in the deployment process of an application to prevent against security risks induced by malformed code. We will see however, that Java Card offers some flexibility to determine when and how verification must be applied.
The Java Card Virtual Machine, Runtime Environment and APIs are designed to run security services on tamper-resistant, secure hardware, and in many cases with limited memory and CPU resources. Some secure elements for example may only have 2 or 4 KB of RAM, and 16-32 bit CPUs. On very resource-constrained hardware, a Java Card implementation may not have enough memory to perform verification on the device itself. To address this scenario, the Java Card specification includes a stand-out feature in allowing a split-VM architecture: verification can either be processed inside the device (on-device or on-card verification) as is the case for the standard Java Virtual Machine for example, or outside the device with an off-device or off-card verifier tool coming with an abstract interpreter.
To support that flexibility, Oracle provides the Java Card Off-Card verifier as a standard tool that can be used for off-device verification. Other similar tools may be available from Java Card licensees.
When verification is performed off-device, several security conditions need to be enforced to prevent execution of corrupted code:
◉ The latest version of the verifier tool needs to be used to perform up-to-date security checks. In the case of the Oracle Java Card Verifier, the latest version can be found as a free download on the Oracle website.
◉ Verification must use export files that are binary compatible with API packages installed on the device.
◉ After verification, the CAP file to be executed on the device is not altered in a way that does not satisfy the constraints checked by this verification.
Another aspect of the split-VM architecture is that data needed for verification is optional and packaged separately from the data needed for the actual execution of the code within a CAP file. This design avoids embedding data that would be unused by a product without on-device verification capabilities. The deployment model acknowledges that a Java Card application can be installed by multiple service providers, managing the installation of optional CAP file components (including those used for verification) in a variety of ways, and on Java Card products with different on-device verification capabilities.
As a consequence, even if off-device verification is not strictly a mandate in the specs (it can be done on-device instead), off-device verification has become a pre-requisite in the Java Card deployment ecosystem. Systematic off-card verification ensures that verification is performed, independently of the on-device capabilities of Java Card product that may be rolled out in future phases of deployment.
Chain of Trust and AAA+ service
The second pillar of the deployment model is based on application management and communication protocols, such as the ones defined by GlobalPlatform, to securely administrate a Java Card product: installation, update, removal of applications and credentials associated with applications. The principle is to enforce a chain of trust starting from the source of a CAP file and based on a AAA+ service: identification, authentication, authorization, Accountability/non-repudiation are guaranteed for each management operation.
CAP files are installed on a Java Card product either at manufacture with specific accreditation and certification, or once deployed in the field by using a Remote Service Manager and through secure channels. In any case, cryptographic keys guarantee an application deployment is secure (confidentiality and integrity) and performed only by an authenticated entity having a granted authorization. In other words, keys are needed to administrate a Java Card product, and it is not possible to install an application without breaking the chain of trust that manages those keys.
The entity or entities deploying applications must anticipate the range of on-device verification capabilities of the targeted Java Card products, and will deploy applications only having the guarantee that the code is verified at some point in time prior its execution either off-device or on-device. As mentioned in the previous section, state of the art is to perform verification of applications off-device prior any deployment to avoid any risk: even if verification is also performed on-device, it prevents from having a corrupted CAP file that may lead to a denial of service for instance.
Security Evaluation & Certification
Products certification is the only mean to bring trust in an open ecosystem. Java Card is widely used in Finance, ID, Mobile and IoT markets. Without trust no one can accept to be liable for a given business risk.
To facilitate Common Criteria certification, Oracle provides a Java Card Protection Profile that helps vendors meet the demand of banks, governments, and other secure device issuers for security evaluations. Verification is a mandatory requirement in order to obtain Common Criteria certification, and is required by the Java Card protection profile.
In addition, in order to adhere to hardware and software certification requirements or as an additional product differentiation, Java Card vendors may choose to have additional and different types of security checks that are performed at runtime, focusing on the execution behavior such as:
◉ security counter measures against logical attacks that may happen if the integrity of the flow from verification to the installation is compromised or memory corrupted after code has been installed in the device: protection against stack or objects overflows, invalid execution paths or illegal code jump, illegal entry point access, type confusion ...
◉ or counter measures against physical attacks, faults attacks or side channel attacks that may happen during execution.
Depending on the deployment scenario (e.g. multiple entities authorized to provide applications for a device), or the condition of utilization of a device (e.g. devices exposed to high risk of physical attacks or lacking hardware countermeasures), application deployers may elect to choose Java Card products with those additional security checks, as an additional protection layer in addition to verification and a chain of trust.
Source: oracle.com
Posts
0 comments:
Post a Comment