Transcript New Security Issues Raised by Open Cards

New Security Issues Raised by Open Cards
Pierre Girard
Jean-Louis Lanet
GERMPLUS R&D
I think it would be better if the title is:
New Security issues Raised by Java Cards
Just simply think they are the same thing. (They are actually
the same thing anyway.)
Outline:
• Some background.
– Smart cards.
– Java Cards.
• Two special concerns about Java Card security.
– Applet download framework.
– Object sharing mechanism.
• An interesting point. (an easy point, from where you can
start your attack.)
• Question.
• Conclusion.
Some Background:
• Smart Card:
– A piece of plastic of the same size as a normal credit
card.
– Embedded with a processor and an array of memory.
(not in all cards)
– The most sophisticated ones contain 32-bit instruction
sets, with several Mbytes of memory. (Amazing, isn’t
it?)
Commands
Results
•Java Card:
– Smart cards capable of running Java byte codes.
– Java Card Architecture:
Applet
Applet
Applet
Industry Add on Classes
Chip-independent
Java Card API
Java Virtual Machine (JVM)
Java Card framework & JCRE
OS & Native Functions
Processor
Chip-dependent
•Java Card (continued)
–
Three important features:
1.
2.
3.
Services (Applets) can run on multiple platforms. (Write once, run
anywhere.)
Support post-issuance applet download.(like install a new software
package on your PC). This can be done easily. (You can do it)
Multiple services (applets) can exist in one card.(like multiple
software packages existing in the hard disk of your PC)
Enough of background, hopefully.
Two special concerns about Java Card security
• The first concern aims to the post-issuance applet
download feature.
– Unlike chip-dependent applications developing. Java
tech is widely spread and relatively easy to get
expertise, also, the process of applet download is
technically easy. So, we can expect that the popularity
of the hacker community of Java Card is likely to be
huge. Then, what if someone tamper a service
provider’s codes or write a piece of malicious code and
download it into a card? (Every one in the class can do
that :=).
•The first concern aims to the post-issuance applet
download feature (continued).
Not that easy unfortunately:=(
– Solution by Open Card Download Framework: All service
providers (applet code developers) must submit their codes to a
publicly trustworthy third party (the checker) before their codes are
downloaded to the customers’ cards. The checker makes an offcard inspection to the codes carefully to ensure that the code is
safe, then he puts a digital signature in the code and sends the code
with the signature back to the service provider. On the card side,
the JVM will use the checker’s public key which is stored in the
card when the card is initialized, to decrypt the checker’s signature.
The JVM will decline to execute an applet without the signature of
the checker, or in case of a tampering to the code is detected after
the code is signed by the checker.
•The second concern aims to the multi-services
feature
– What about if a service provider attempts to steal sensitive data
(keys and values) from other services in the same card through
access to the data fields and methods of other services?
– Solution by the Java Card object sharing mechanism: The
minimum downloadable unit is a package or an applet (not a class,
Java Card doesn’t support dynamic class loading). Each package
has its own context (you can think it as a memory domain) in the
card. If codes in one context attempt to access data or codes in
another context, the JVM will invoke a program called the Applet
Firewall (AF), to see whether the callee is declared as sharable by
that particular caller or all other callers. If it is, the JVM will do a
context switch to the callee’s context and execute, then do another
context switch back to the caller’s context with the result passed
back. Otherwise a runtime exception will be propagated up.
It seems all the back doors are tightly closed!!!!
But is it really safe then????
•An interesting point (an easy point from where
you can start your attack)
– My first feeling to this point is somewhat like: “Everything is
perfect, but……a little tail up there”.
– Java Card Framework (JCF) security mechanism doesn’t deal with
native method calls at all. That means you can embed native
methods in your applets, then you can completely bypass the
security guard provided by the JCRE and make direct calls to the
OS libraries. That also means you can do whatever you want!
– Why? I don’t know. (My guess) The JCF wants to leave some
flexibilities to the applet developers to use functions provided by
the card OS libraries that are not covered by the JCF API. Another
reason is possibly for gaining better code performance.
– Then we have another problem.
Question:
What is/are needed to avoid erroneous/malicious
misuse of native methods?
My answer:
• A more sophisticated Open Card Download Framework.
• The OCDF should define a set of rules for restriction use
of native methods.
• The checker (a publicly trustworthy authority) should have
good knowledge of all card platforms in the market, in
order to check out all potentially dangerous OS library
calls, and then decline to sign the code.
• In a multi-card-issuers and multi-service-providers
environment, things will get much more complicated. A
higher level of back-end card management facility is
needed.
Conclusion:
While Java cards provide useful and convenient features to
service-oriented application developers and end users,
however, it is these features that introduce new security
issues. Although the Java Card Frame work has provided
means to cope with these problems, but the incorporation
with some effective off-card, back-office check is a mustneed to ensure full-scale security, and also, this back-end part
is the hard part in the security system of the Java Card world.