Closed dmercer-google closed 4 years ago
Until this is resolved please pass the scp and scpimpl (https://github.com/kaoh/globalplatform/blob/master/gpshell/src/gpshell.1.md) parameters manually, then this call is not executed. In focus of gpshell has been the installation of applets against a security domain, I'm not sure about the support for STORE DATA to pass parameters to an applet, e.g a GP SEAC applet. This must be encoded manually currently, I guess.
This behavior is a remaining artifact from OpenPlatform 2.0.1 card. These have not reported the scp and scpimpl. But I think I know also how to detect also these cards to make the a priori knowledge of the scp and scpiml not necessary.
BTW: What OS are you using? Are you compiling this on your own or are you using pre-built binaries?
I now remember the actual reason for this: Detecting the SCP alone is easy, but in the specification for SCP02 it was forgotten to return the SCP implementation information (SCP implementation is a sub mode of the SCP, i.e. an additional parameter) in initialize update, hence it must be known a priori. So the expectation of this fix can only be that the SCP is detected, but not the SCP implementation. GP Pro does not care here about the details and assumes here a often used default of 0x55, but I assume this can fail in not just a few cases, I was striving here for more completeness. I have to think again about maybe a different way, currently I have no good solution for SCP02 for the auto detection. Maybe the called get_data command must be called initially before selecting the applet and it should remember the found values.
Check this (Windows binary): https://drive.google.com/file/d/1DnIuAO5LMEYrWQ3CFJsG2zuvRushAUaB/view?usp=sharing
There is a new command get_secure_channel_protocol_details
. This must be executed after the security domain is selected. After this is executed you can call you own applet and do the mutual authentication.
Example script:
mode_211
enable_trace
establish_context
card_connect
select -AID a0000000030000
get_secure_channel_protocol_details
open_sc -security 3 -keyind 0 -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f -kek_key 404142434445464748494a4b4c4d4e4f // Open secure channel
get_status -element 10
get_status -element 20
get_status -element 40
get_status -element 80
card_disconnect
release_context
The new command is also covered in https://github.com/kaoh/globalplatform/blob/master/gpshell/src/gpshell.1.md
Sorry for the latency in replying. calling get_secure_channel_protocol_details after the Security domain has been selected solves this issue. Thanks.
Closing.
BTW: I am compiling on my own for Linux
OK, great that it works. I have also added support for install_for_personalization
and store_data
in GPShell. In case this is convenient to be able to talk to the applet.
When GPShell processes the open_sc command it first sends get_data fir the card data tag 66 (00CA006600). This is then followed by an initialize update and external authenticate.
When a JavaCard applet is selected and open_sc is then called the Applet must be able to process the get_data command. The problem is that JavaCard applets have no visibility into card data so the response would have to be hard coded for every card an applet is supposed to run on.
A better way to get the needed SCP parameters is to look at the key information field of the initialize update response which gives the key version and the SCP version used by the card. Initialize update and external authenticate can be handled by JavaCard.
An example of where this is done can be seen in the GlobalPlatformPro application