A User Centric Security Model for Tamper-Resistant Devices

5.5 Card Management-Related Issues
5.5.3 Parasite Application Problem
In the parasite application problem, an installed application masquerades as the UCTD
on which it is installed. This is possible because a UCTD allows an installed application
to request the platform/application state validation from the TEM (section 4.3).
Service Provider
3) Request
Validation
6) Application
Download
5) Validation
Proof
2) Request
Validation
1) Request
Application
App Malicious
4) Validation
Smart Card Runtime Environment
Trusted Environment & Execution Manager (TEM)
User Centric Tamper-Resistant Device
7) Transfer
Application Off-card
3a) Request Online
Validation
3b) Online
Validation
Figure 5.5: Illustration of parasite application problem
Malicious User
Smart Card
Manufacturer
In this attack as shown in gure 5.5, an adversary (A) installs his malicious application
(App Malicious ) on a UCTD. The App Malicious implements the application download protocols
that are discussed in chapter 6. The A then requests the installation of an application
from its SP through the App Malicious , represented by message one in the gure 5.5. In
response, the SP asks the UCTD of security validation to avoid a simulator attack and this
request is sent to the App Malicious . The App Malicious then asks the TEM for the security
validation (section 4.4.3). At the successful conclusion of the security validation process,
the card manufacturer produces a certicate that for privacy reasons does not include
the identity of the requesting SP as described in the online attestation protocol (section
4.7). Therefore, the App Malicious can communicate this certicate to the requesting SP
as validation in message ve (gure 5.5) and may be able to start the application download
process. The A might have designed the application as if it will communicate the
downloaded application o-card, which will enable A to retrieve the application code and
data.
To avoid this problem, there are four possible solutions: 1) restrict the security assurance
validation request to o-card entities and any installed applications should not be allowed
to request it, 2) include the identity of the requesting SP in the security assurance validation
certicate during the application installation process, 3) include the identity of
the application requesting the security assurance validation during the application installation,
the request is initiated by the card security manager discussed in section 4.2.2, or
4) avoid generating the signature as part of the security validation if it is requested by an
application, but use the shared keys between the TEM and the application.
125