Application-Specific Authentication on Resource-Constrained Devices

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Resource-constrained devices like smart cards face challenges in secure and flexible communication due to limited resources, inadequate authentication mechanisms, and cumbersome virtual hosting implementations, leading to security and efficiency issues in transactions.

Innovation Solution

Implementing a method that uses application-specific secure ports and a transport security layer to authenticate client requests, establishing direct secure connections, and dynamically allocating secure ports for each application, thereby eliminating the need for proxies and enhancing security and flexibility in communication.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If HTTPS is used for server authentication, then communication security is improved, but client authentication is not provided and generic authentication at server level is insufficient for multiple applications

Engineering Contradiction:
Improvecommunication securityVSAvoidauthentication capability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent segments the authentication mechanism from the server level to the application level. Each application on the smart card is assigned its own authentication credentials (private key and certificate), allowing individual application authentication rather than generic server-level authentication. This enables multiple applications to have distinct authentication capabilities while maintaining security.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a certificate authority (CA) as an intermediary that issues certificates to both servers and clients. The CA-signed certificates enable mutual authentication between applications on the smart card and off-card applications, providing a trusted third-party mechanism for verifying identities at the application level.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If multiple applications are supported on smart card, then service versatility is improved, but resource constraints make authentication of each application problematic

Engineering Contradiction:
Improveservice capabilityVSAvoidauthentication reliability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements a universal authentication framework based on public key infrastructure that works across multiple applications. Each application uses the same cryptographic primitives (asymmetric encryption, digital signatures) but with application-specific keys and certificates, providing consistent authentication reliability across diverse services.

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

Solution Approach 2:

The patent changes the authentication parameters from shared server-level credentials to application-specific credentials. Each application is provisioned with its own private key and certificate, transforming the authentication mechanism to support multiple applications while maintaining security through parameter differentiation.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If proxy is used for protocol translation, then communication flexibility is improved, but security is worsened due to decryption and re-encryption exposing sensitive information

Engineering Contradiction:
Improveprotocol compatibilityVSAvoiddata exposure risk
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The patent extracts the protocol translation function from the proxy and relocates it to the application layer. Applications on the smart card directly handle multiple protocols (ISO 7816, Java Card, HTTP) without requiring intermediate decryption and re-encryption, eliminating the security vulnerability while maintaining protocol flexibility.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent implements multiple protocol stacks directly on the smart card, creating copies of protocol handling capabilities within the constrained environment. This allows applications to communicate using different protocols without external translation, eliminating the need for insecure proxy-based translation.

Inventive Principle:
Principle #26Copying

4Adaptability or versatility

If virtual hosting is implemented on smart card, then application hosting capability is improved, but device complexity increases due to manual configuration requirements

Engineering Contradiction:
Improveapplication hosting capabilityVSAvoidconfiguration complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements automatic virtual hosting where applications self-configure their network parameters. The smart card system automatically assigns IP addresses, ports, and routing information to applications without manual configuration, enabling virtual hosting capability while reducing complexity through automated service provisioning.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS8484713B1Transport-level web application security on a resource-constrained device
Publication Date: 2013.07.09 ORACLE AMERICAN INC
  • US8484713B1 patent drawing
  • US8484713B1 patent drawing
  • US8484713B1 patent drawing

AI summary

A system and method is provided to facilitate secure communications for a server-application executing on a resource-constrained device. A request, from a client application executing on a client device to access a server application executing on the resource-constrained device is received on an application-specific secure port of a resource-constrained device. The request is authenticated using a security token stored in an application context of the server application. The authentication is performed by a transport security layer protocol executing within the application context of the server application. The security token is specific for the server application. A secure connection is established directly between the secure port and the client application upon the authentication being successful.