Secure Element Native Code Loading via Custom CAP

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for fixing bugs in native code of Java Card-based secure elements post-issuance are insecure and costly, as they require proprietary loaders that can lead to security vulnerabilities and need extensive review by security labs, and there is no efficient method to ensure only authorized parties can load native code corrections.

Innovation Solution

A method involving the creation of a modified CAP file with a custom CAP component containing native code corrections, which includes a platform's signature for authentication, allowing only authorized parties to load and install the corrections by embedding this signature within the CAP file, ensuring secure and efficient deployment.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of repair

If a proprietary loader is implemented inside the secure element to load native code corrections, then native code bugs can be fixed post-issuance, but security vulnerabilities increase and extensive review by security labs is required

Engineering Contradiction:
Improvepost-issuance bug fixing capabilityVSAvoidsecurity vulnerability
Core Design Contradiction:
Ease of repairVSReliability

Solution Approach 1:

The patent applies universality by making the existing Java Card Virtual Machine and its standard loading mechanisms multi-functional. Instead of creating a separate proprietary loader, the existing JVM infrastructure is extended to handle native code corrections through standard CAP file loading, allowing the same loading path to serve both Java applets and native code patches, thereby reducing security review requirements while maintaining post-issuance fix capability

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces an intermediary mechanism in the form of a custom CAP component that acts as a mediator between the correction package and the native code. This intermediary structure allows the existing secure loading infrastructure to handle native code corrections without requiring direct proprietary loader implementation, thus maintaining security while enabling bug fixes

Inventive Principle:
Principle #24Intermediary (Mediator)

2Ease of repair

If a proprietary loader is implemented to load native code corrections, then post-issuance fixing is enabled, but deployment complexity and security lab review requirements increase

Engineering Contradiction:
Improvepost-issuance bug fixing capabilityVSAvoiddeployment complexity
Core Design Contradiction:
Ease of repairVSDevice complexity

Solution Approach 1:

The solution makes the existing CAP file loading infrastructure multi-functional by enabling it to handle both traditional Java applets and native code corrections through the same standardized mechanism, eliminating the need for separate proprietary loading procedures and reducing deployment complexity

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent changes the parameter of the CAP file format by introducing a custom component type that specifies native code content. This parameter change allows the existing loading system to automatically recognize and process native code corrections without requiring complex proprietary loading procedures, thereby simplifying deployment

Inventive Principle:
Principle #35Parameter changes

3Ease of operation

If native code corrections are loaded without authentication, then loading process is simple, but unauthorized parties can inject malicious code

Engineering Contradiction:
Improveloading process simplicityVSAvoidmalicious code injection
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The patent introduces an intermediary authentication mechanism through the custom CAP component structure. The component includes metadata and signature fields that act as intermediaries between the correction package and the loading system, enabling automatic verification of authorization without complicating the loading process for authorized parties

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements feedback through signature verification and authorization checks that provide immediate feedback on whether a correction package is authorized. This feedback mechanism allows the system to automatically accept or reject corrections without requiring complex manual review processes, maintaining simplicity while ensuring security

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3074911B1Method for loading a native code on a secure element
Publication Date: 2019.12.04 THALES DIS FRANCE SA
  • EP3074911B1 patent drawingFigure 1
  • EP3074911B1 patent drawingFigure 2~3

AI summary

The invention relates to a method for loading at least one native code on at least one target secure element comprising a java card virtual machine, said method comprising the following steps: providing a modified CAP file (110) composed of at least one custom CAP component (101) comprising a native code; extracting said native code from the custom CAP component; installing said native code in the target secure.