Can we extract an installed (or downloaded) applet from java card?
is it possible?
Extract applet from java card
-
aahmadzadeh
- Posts: 27
- Joined: Mon Sep 28, 2015 2:31 am
- Points :400
- Contact:
Re: Extract applet from java card
No. only via back door
Re: Extract applet from java card
It's impossible. If that can be done, javacard is not a secure carrier any more.
-
aahmadzadeh
- Posts: 27
- Joined: Mon Sep 28, 2015 2:31 am
- Points :400
- Contact:
Re: Extract applet from java card
rena2019 wrote:No. only via back door
what is your mean of back door??
-
aahmadzadeh
- Posts: 27
- Joined: Mon Sep 28, 2015 2:31 am
- Points :400
- Contact:
Re: Extract applet from java card
mabel wrote:It's impossible. If that can be done, javacard is not a secure carrier any more.
even if i have key set of java card?
Re: Extract applet from java card
aahmadzadeh wrote:mabel wrote:It's impossible. If that can be done, javacard is not a secure carrier any more.
even if i have key set of java card?
Yes, even if you have the key set of java card, you can not extract the applet from the card either.
Re: Extract applet from java card
aahmadzadeh wrote:rena2019 wrote:No. only via back door
what is your mean of back door??
If the card supplier has a patch script to use some propriatery commands to dump EEPROM. But for 'normal customers' it's not possible to use it
Re: Extract applet from java card
Please read the GlobalPlatform specification linked below for more details on Card Manager keyset. It is beneficial for beginners to have an understanding on how GlobalPlatform standards and it's specifications work.
Will there be backdoors where your card issuer/IC manufacturer can patch some nasty stuff ? Possible but this is very obvious if you run a module between the card and reader and inspect the commands. The better way to backdoor a card is to deliberately introduce logic flaws in the JCOS codes (i.e. weakened Firewall) and then write a malicious applet, load it into the card and exploit the deliberately weakened firewall. That is also one reason why some card solution creators (o.e. FIDO token - Yubico/Yubikey) refuse to hand over the GP ISD keys so that they have a monopoly over the environment.
I am not implying that Yubico tokens have any backdoors nor am I denying it because I do not use Yubico/Yubikeys (I prefer to write my own applets that i use from scratch and study the protocols to be on the safer side) but I am showing that the better way to control an environment is controlling the GP ISD keys as it secure the environment from others but the creator and it allows the creator to do what he/she wants (loading/deleting applets).
Can applets be extracted from a JavaCard ? The short and most direct answer is no if you were to read the GP standards linked below. The long and indirect answer is that practical implementations are very different from theoretical standards... so .. who knows ....
This has always been a tricky and weird question as I also asked them many times (to other people) in the past and itching to find out despite the GP standards not including the function to extract, the practical aspect is unknown ... unless ... you decap the IC chip with those FIB workstation lasers, probes ... highly expensive, advanced and time consuming physical attacks on a whole ton of spare IC chips to find your answer in the (EEP)ROM/FLASH JCOS and native codes sitting inside the IC chip.
In the inevitability that the applet gets leaked via some backdoor or something happens, the next obvious step is to obfuscate your applet codes although that introduces a layer of complexity in itself and this comes back to the question, how much security and what is your security and threat model for your situation. If you are defending against an adversary/ies who is/are known to be highly sophisticated and have tonnes of resources to spend, you have to start thinking of splitting up your secrets onto multiple cards, different IC chip makers, different COS systems and even keep some split secrets (assuming some secret sharing scheme like Shamir Secret Sharing) by writing some secret share portions onto pieces of easily flammable cigarette papers where in an instant, you can use a lighter or a match stick to quick dispose some of the physical secret shares to render the highly sensitive secret unusable even if the adversary manages to decap some chips.
Link: http://www.win.tue.nl/pinpasjc/docs/GPCardSpec_v2.2.pdf
Will there be backdoors where your card issuer/IC manufacturer can patch some nasty stuff ? Possible but this is very obvious if you run a module between the card and reader and inspect the commands. The better way to backdoor a card is to deliberately introduce logic flaws in the JCOS codes (i.e. weakened Firewall) and then write a malicious applet, load it into the card and exploit the deliberately weakened firewall. That is also one reason why some card solution creators (o.e. FIDO token - Yubico/Yubikey) refuse to hand over the GP ISD keys so that they have a monopoly over the environment.
I am not implying that Yubico tokens have any backdoors nor am I denying it because I do not use Yubico/Yubikeys (I prefer to write my own applets that i use from scratch and study the protocols to be on the safer side) but I am showing that the better way to control an environment is controlling the GP ISD keys as it secure the environment from others but the creator and it allows the creator to do what he/she wants (loading/deleting applets).
Can applets be extracted from a JavaCard ? The short and most direct answer is no if you were to read the GP standards linked below. The long and indirect answer is that practical implementations are very different from theoretical standards... so .. who knows ....
This has always been a tricky and weird question as I also asked them many times (to other people) in the past and itching to find out despite the GP standards not including the function to extract, the practical aspect is unknown ... unless ... you decap the IC chip with those FIB workstation lasers, probes ... highly expensive, advanced and time consuming physical attacks on a whole ton of spare IC chips to find your answer in the (EEP)ROM/FLASH JCOS and native codes sitting inside the IC chip.
In the inevitability that the applet gets leaked via some backdoor or something happens, the next obvious step is to obfuscate your applet codes although that introduces a layer of complexity in itself and this comes back to the question, how much security and what is your security and threat model for your situation. If you are defending against an adversary/ies who is/are known to be highly sophisticated and have tonnes of resources to spend, you have to start thinking of splitting up your secrets onto multiple cards, different IC chip makers, different COS systems and even keep some split secrets (assuming some secret sharing scheme like Shamir Secret Sharing) by writing some secret share portions onto pieces of easily flammable cigarette papers where in an instant, you can use a lighter or a match stick to quick dispose some of the physical secret shares to render the highly sensitive secret unusable even if the adversary manages to decap some chips.
Link: http://www.win.tue.nl/pinpasjc/docs/GPCardSpec_v2.2.pdf
Who is online
Users browsing this forum: No registered users and 54 guests