Menu
▾
▴
globalplatform-developers — Mailing List for Developers of this Project
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
(18) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(15) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
| 2014 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
|
May
(2) |
Jun
(3) |
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
|
From: Karsten O. <wid...@t-...> - 2020-12-01 13:17:21
|
Hi Agostino, Have a look into the code where the card challenge is generated. AFAIR there are 2 modes: Real random and pseudo random. Pseudo random has the advantage that APDU scripts can be pre-computed, i.e. they can be later replayed to the card. Please consult the GlobalPlatform card specification for details. Karsten On 01/12/2020 10:00, Sette Agostino via Globalplatform-developers wrote: > > Hi Karsten, > > > > I am sorry but I forgot one point which could be useful to better > explain my problem: > > I would like to ask you, because it is not clear to us, if the card > challenge is generated randomly or in a deterministic way with the > AES128-CMAC. > > Thanks once again > > > > Kind Regards > > > > Agostino Sette > > > > > > *Da:*Sette Agostino > *Inviato:* martedì 1 dicembre 2020 09:43 > *A:* 'Karsten Ohme' <wid...@t-...>; > glo...@li... > *Oggetto:* R: [EXT] Re: [Globalplatform-developers] Card Challenge > generation on SCP93 > > > > Hi Karsten, > > > > First of all thank you for the reply. > > I answer to your questions inline in your email. > > Kind Regards > > > > Agostino Sette > > > > *Da:*Karsten Ohme <wid...@t-... > <mailto:wid...@t-...>> > *Inviato:* lunedì 30 novembre 2020 23:05 > *A:* glo...@li... > <mailto:glo...@li...> > *Oggetto:* [EXT] Re: [Globalplatform-developers] Card Challenge > generation on SCP93 > > > > Hi, > > > > The test vector from the SCP03 test should be OK. > > [Agostino] Yes, it is. > > Could you describe your problem? > > [Agostino] I would like to understand how you obtain the card > challenge, what parameters are used and if what I make to generate it > is correct, in a very easy way. > > You are not able to replicate the result from the test with your own code? > > [Agostino] No, I am not able to replicate the result from the test > with my own code. I try to clarify: if I use the host challenge and > the card challenge derived from scp03Test.c, from that point on in the > mutual authentication phase looks good. A part from host challenge, I > would like to understand the card challenge generation, that’s all. > > A step-by-step debugging of the scp03Test in e.g. Eclipse C/C++ IDE > should give you all the intermediate steps so that you can compare the > libraries and your result. > > [Agostino] I will try again but I haven’t found a .project file for > eclipse. Furthermore I am not using libraries at the moment. > > What is the goal? Implement the server side on a smart card? > > [Agostino] The goal is to implement both the server and the smart card > side. > > Add support for a different programming language? > > [Agostino] The used programming language is C > > I think there are already OS projects for Java, Python and C. > > [Agostino] I will appreciate if you could suggest me OS projects for C. > > > > Karsten > > On 30/11/2020 15:21, Sette Agostino via Globalplatform-developers wrote: > > Hi, > > > > I am trying to develop my own SCP03 protocol and for this reason I > cloned this > > > > git clone https://git.code.sf.net/p/globalplatform/git > <https://git.code.sf.net/p/globalplatform/git> globalplatform-git > > > > as a starting point, first to understand how to proceed and then > to check if what I did was correct. > > I verified almost everything except the Card Challenge, to be > clear I would like to know how it is generated. > > As far a I know it should be generated as follows: > > > > Card challenge (8 bytes) (with PRNG): > > AES-CMAC (Key-ENC , 0x00 00 00 00 00 00 00 00 00 00 00 02 00 00 40 > 01 || context) > > “context“: concat. of sequence counter (3 bytes) and AID of the > application invoking the SecureChannel (5 to 16 bytes). > > > > Starting from the information on the file > > > > globalplatform/git/ci/master/tree/globalplatform/src/scp03Test.c > > > > I assumed that: > > 1. Key-ENC = {0xF9, 0x95, 0xD0, 0xA0, 0x69, 0x33, 0x5C, 0x7D, > 0xF4, 0x2E, 0x59, 0x03, 0x17, 0xFF, 0xEA, 0x6D}; > 2. Sequence counter = {0x00, 0x00, 0x15}; > 3. AID = {0xA0, 0x01, 0x00, 0x01, 0x51, 0x41, 0x43, 0x4C}; > > > > The result card challenge, present on the same file into the > “initializeUpdateResponse” is > > > > Card Challenge = {0xC4, 0x09, 0x32, 0xA6, 0xFE, 0xFE, 0xAE, 0xB2}; > > > > First of all, is all this correct? > > > > If yes, > > > | context > > (00000000000000000000000200004001000015A00100015141434C) > > > > And the Key-ENC is > > > > (F995D0A069335C7DF42E590317FFEA6D) > > > > Where I am wrong or what I have forgot? > > Any help would be appreciated. > > > > Thanks in advance > > > > Kind Regards > > Agostino Sette > > > > > > > > _______________________________________________ > > Globalplatform-developers mailing list > > Glo...@li... <mailto:Glo...@li...> > > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers > > > > _______________________________________________ > Globalplatform-developers mailing list > Glo...@li... > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: Karsten O. <wid...@t-...> - 2020-12-01 13:14:04
|
Hi Agostino, Regarding the Eclipse project: you can generate this with cmake: cmake -G "Eclipse CDT4 - Unix Makefiles" . Not this can be imported as a new project from an existing Makefile. --- An OS project for C is this project. Karsten On 01/12/2020 09:43, Sette Agostino via Globalplatform-developers wrote: > > Hi Karsten, > > > > First of all thank you for the reply. > > I answer to your questions inline in your email. > > Kind Regards > > > > Agostino Sette > > > > *Da:*Karsten Ohme <wid...@t-...> > *Inviato:* lunedì 30 novembre 2020 23:05 > *A:* glo...@li... > *Oggetto:* [EXT] Re: [Globalplatform-developers] Card Challenge > generation on SCP93 > > > > Hi, > > > > The test vector from the SCP03 test should be OK. > > [Agostino] Yes, it is. > > Could you describe your problem? > > [Agostino] I would like to understand how you obtain the card > challenge, what parameters are used and if what I make to generate it > is correct, in a very easy way. > > You are not able to replicate the result from the test with your own code? > > [Agostino] No, I am not able to replicate the result from the test > with my own code. I try to clarify: if I use the host challenge and > the card challenge derived from scp03Test.c, from that point on in the > mutual authentication phase looks good. A part from host challenge, I > would like to understand the card challenge generation, that’s all. > > A step-by-step debugging of the scp03Test in e.g. Eclipse C/C++ IDE > should give you all the intermediate steps so that you can compare the > libraries and your result. > > [Agostino] I will try again but I haven’t found a .project file for > eclipse. Furthermore I am not using libraries at the moment. > > What is the goal? Implement the server side on a smart card? > > [Agostino] The goal is to implement both the server and the smart card > side. > > Add support for a different programming language? > > [Agostino] The used programming language is C > > I think there are already OS projects for Java, Python and C. > > [Agostino] I will appreciate if you could suggest me OS projects for C. > > > > Karsten > > On 30/11/2020 15:21, Sette Agostino via Globalplatform-developers wrote: > > Hi, > > > > I am trying to develop my own SCP03 protocol and for this reason I > cloned this > > > > git clone https://git.code.sf.net/p/globalplatform/git > <https://git.code.sf.net/p/globalplatform/git> globalplatform-git > > > > as a starting point, first to understand how to proceed and then > to check if what I did was correct. > > I verified almost everything except the Card Challenge, to be > clear I would like to know how it is generated. > > As far a I know it should be generated as follows: > > > > Card challenge (8 bytes) (with PRNG): > > AES-CMAC (Key-ENC , 0x00 00 00 00 00 00 00 00 00 00 00 02 00 00 40 > 01 || context) > > “context“: concat. of sequence counter (3 bytes) and AID of the > application invoking the SecureChannel (5 to 16 bytes). > > > > Starting from the information on the file > > > > globalplatform/git/ci/master/tree/globalplatform/src/scp03Test.c > > > > I assumed that: > > 1. Key-ENC = {0xF9, 0x95, 0xD0, 0xA0, 0x69, 0x33, 0x5C, 0x7D, > 0xF4, 0x2E, 0x59, 0x03, 0x17, 0xFF, 0xEA, 0x6D}; > 2. Sequence counter = {0x00, 0x00, 0x15}; > 3. AID = {0xA0, 0x01, 0x00, 0x01, 0x51, 0x41, 0x43, 0x4C}; > > > > The result card challenge, present on the same file into the > “initializeUpdateResponse” is > > > > Card Challenge = {0xC4, 0x09, 0x32, 0xA6, 0xFE, 0xFE, 0xAE, 0xB2}; > > > > First of all, is all this correct? > > > > If yes, > > > | context > > (00000000000000000000000200004001000015A00100015141434C) > > > > And the Key-ENC is > > > > (F995D0A069335C7DF42E590317FFEA6D) > > > > Where I am wrong or what I have forgot? > > Any help would be appreciated. > > > > Thanks in advance > > > > Kind Regards > > Agostino Sette > > > > > > > > > _______________________________________________ > > Globalplatform-developers mailing list > > Glo...@li... <mailto:Glo...@li...> > > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers > > > > _______________________________________________ > Globalplatform-developers mailing list > Glo...@li... > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: Sette A. <ago...@te...> - 2020-12-01 09:01:04
|
Hi Karsten, I am sorry but I forgot one point which could be useful to better explain my problem: I would like to ask you, because it is not clear to us, if the card challenge is generated randomly or in a deterministic way with the AES128-CMAC. Thanks once again Kind Regards Agostino Sette Da: Sette Agostino Inviato: martedì 1 dicembre 2020 09:43 A: 'Karsten Ohme' <wid...@t-...>; glo...@li... Oggetto: R: [EXT] Re: [Globalplatform-developers] Card Challenge generation on SCP93 Hi Karsten, First of all thank you for the reply. I answer to your questions inline in your email. Kind Regards Agostino Sette Da: Karsten Ohme <wid...@t-...<mailto:wid...@t-...>> Inviato: lunedì 30 novembre 2020 23:05 A: glo...@li...<mailto:glo...@li...> Oggetto: [EXT] Re: [Globalplatform-developers] Card Challenge generation on SCP93 Hi, The test vector from the SCP03 test should be OK. [Agostino] Yes, it is. Could you describe your problem? [Agostino] I would like to understand how you obtain the card challenge, what parameters are used and if what I make to generate it is correct, in a very easy way. You are not able to replicate the result from the test with your own code? [Agostino] No, I am not able to replicate the result from the test with my own code. I try to clarify: if I use the host challenge and the card challenge derived from scp03Test.c, from that point on in the mutual authentication phase looks good. A part from host challenge, I would like to understand the card challenge generation, that's all. A step-by-step debugging of the scp03Test in e.g. Eclipse C/C++ IDE should give you all the intermediate steps so that you can compare the libraries and your result. [Agostino] I will try again but I haven't found a .project file for eclipse. Furthermore I am not using libraries at the moment. What is the goal? Implement the server side on a smart card? [Agostino] The goal is to implement both the server and the smart card side. Add support for a different programming language? [Agostino] The used programming language is C I think there are already OS projects for Java, Python and C. [Agostino] I will appreciate if you could suggest me OS projects for C. Karsten On 30/11/2020 15:21, Sette Agostino via Globalplatform-developers wrote: Hi, I am trying to develop my own SCP03 protocol and for this reason I cloned this git clone https://git.code.sf.net/p/globalplatform/git globalplatform-git as a starting point, first to understand how to proceed and then to check if what I did was correct. I verified almost everything except the Card Challenge, to be clear I would like to know how it is generated. As far a I know it should be generated as follows: Card challenge (8 bytes) (with PRNG): AES-CMAC (Key-ENC , 0x00 00 00 00 00 00 00 00 00 00 00 02 00 00 40 01 || context) "context": concat. of sequence counter (3 bytes) and AID of the application invoking the SecureChannel (5 to 16 bytes). Starting from the information on the file globalplatform/git/ci/master/tree/globalplatform/src/scp03Test.c I assumed that: 1. Key-ENC = {0xF9, 0x95, 0xD0, 0xA0, 0x69, 0x33, 0x5C, 0x7D, 0xF4, 0x2E, 0x59, 0x03, 0x17, 0xFF, 0xEA, 0x6D}; 2. Sequence counter = {0x00, 0x00, 0x15}; 3. AID = {0xA0, 0x01, 0x00, 0x01, 0x51, 0x41, 0x43, 0x4C}; The result card challenge, present on the same file into the "initializeUpdateResponse" is Card Challenge = {0xC4, 0x09, 0x32, 0xA6, 0xFE, 0xFE, 0xAE, 0xB2}; First of all, is all this correct? If yes, | context (00000000000000000000000200004001000015A00100015141434C) And the Key-ENC is (F995D0A069335C7DF42E590317FFEA6D) Where I am wrong or what I have forgot? Any help would be appreciated. Thanks in advance Kind Regards Agostino Sette _______________________________________________ Globalplatform-developers mailing list Glo...@li...<mailto:Glo...@li...> https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: Sette A. <ago...@te...> - 2020-12-01 08:43:37
|
Hi Karsten, First of all thank you for the reply. I answer to your questions inline in your email. Kind Regards Agostino Sette Da: Karsten Ohme <wid...@t-...> Inviato: lunedì 30 novembre 2020 23:05 A: glo...@li... Oggetto: [EXT] Re: [Globalplatform-developers] Card Challenge generation on SCP93 Hi, The test vector from the SCP03 test should be OK. [Agostino] Yes, it is. Could you describe your problem? [Agostino] I would like to understand how you obtain the card challenge, what parameters are used and if what I make to generate it is correct, in a very easy way. You are not able to replicate the result from the test with your own code? [Agostino] No, I am not able to replicate the result from the test with my own code. I try to clarify: if I use the host challenge and the card challenge derived from scp03Test.c, from that point on in the mutual authentication phase looks good. A part from host challenge, I would like to understand the card challenge generation, that's all. A step-by-step debugging of the scp03Test in e.g. Eclipse C/C++ IDE should give you all the intermediate steps so that you can compare the libraries and your result. [Agostino] I will try again but I haven't found a .project file for eclipse. Furthermore I am not using libraries at the moment. What is the goal? Implement the server side on a smart card? [Agostino] The goal is to implement both the server and the smart card side. Add support for a different programming language? [Agostino] The used programming language is C I think there are already OS projects for Java, Python and C. [Agostino] I will appreciate if you could suggest me OS projects for C. Karsten On 30/11/2020 15:21, Sette Agostino via Globalplatform-developers wrote: Hi, I am trying to develop my own SCP03 protocol and for this reason I cloned this git clone https://git.code.sf.net/p/globalplatform/git globalplatform-git as a starting point, first to understand how to proceed and then to check if what I did was correct. I verified almost everything except the Card Challenge, to be clear I would like to know how it is generated. As far a I know it should be generated as follows: Card challenge (8 bytes) (with PRNG): AES-CMAC (Key-ENC , 0x00 00 00 00 00 00 00 00 00 00 00 02 00 00 40 01 || context) "context": concat. of sequence counter (3 bytes) and AID of the application invoking the SecureChannel (5 to 16 bytes). Starting from the information on the file globalplatform/git/ci/master/tree/globalplatform/src/scp03Test.c I assumed that: 1. Key-ENC = {0xF9, 0x95, 0xD0, 0xA0, 0x69, 0x33, 0x5C, 0x7D, 0xF4, 0x2E, 0x59, 0x03, 0x17, 0xFF, 0xEA, 0x6D}; 2. Sequence counter = {0x00, 0x00, 0x15}; 3. AID = {0xA0, 0x01, 0x00, 0x01, 0x51, 0x41, 0x43, 0x4C}; The result card challenge, present on the same file into the "initializeUpdateResponse" is Card Challenge = {0xC4, 0x09, 0x32, 0xA6, 0xFE, 0xFE, 0xAE, 0xB2}; First of all, is all this correct? If yes, | context (00000000000000000000000200004001000015A00100015141434C) And the Key-ENC is (F995D0A069335C7DF42E590317FFEA6D) Where I am wrong or what I have forgot? Any help would be appreciated. Thanks in advance Kind Regards Agostino Sette _______________________________________________ Globalplatform-developers mailing list Glo...@li...<mailto:Glo...@li...> https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: Karsten O. <wid...@t-...> - 2020-11-30 22:05:01
|
Hi, The test vector from the SCP03 test should be OK. Could you describe your problem? You are not able to replicate the result from the test with your own code? A step-by-step debugging of the scp03Test in e.g. Eclipse C/C++ IDE should give you all the intermediate steps so that you can compare the libraries and your result. What is the goal? Implement the server side on a smart card? Add support for a different programming language? I think there are already OS projects for Java, Python and C. Karsten On 30/11/2020 15:21, Sette Agostino via Globalplatform-developers wrote: > > Hi, > > > > I am trying to develop my own SCP03 protocol and for this reason I > cloned this > > > > git clone https://git.code.sf.net/p/globalplatform/git globalplatform-git > > > > as a starting point, first to understand how to proceed and then to > check if what I did was correct. > > I verified almost everything except the Card Challenge, to be clear I > would like to know how it is generated. > > As far a I know it should be generated as follows: > > > > Card challenge (8 bytes) (with PRNG): > > AES-CMAC (Key-ENC , 0x00 00 00 00 00 00 00 00 00 00 00 02 00 00 40 01 > || context) > > “context“: concat. of sequence counter (3 bytes) and AID of the > application invoking the SecureChannel (5 to 16 bytes). > > > > Starting from the information on the file > > > > globalplatform/git/ci/master/tree/globalplatform/src/scp03Test.c > > > > I assumed that: > > 1. Key-ENC = {0xF9, 0x95, 0xD0, 0xA0, 0x69, 0x33, 0x5C, 0x7D, 0xF4, > 0x2E, 0x59, 0x03, 0x17, 0xFF, 0xEA, 0x6D}; > 2. Sequence counter = {0x00, 0x00, 0x15}; > 3. AID = {0xA0, 0x01, 0x00, 0x01, 0x51, 0x41, 0x43, 0x4C}; > > > > The result card challenge, present on the same file into the > “initializeUpdateResponse” is > > > > Card Challenge = {0xC4, 0x09, 0x32, 0xA6, 0xFE, 0xFE, 0xAE, 0xB2}; > > > > First of all, is all this correct? > > > > If yes, > > > | context > > (00000000000000000000000200004001000015A00100015141434C) > > > > And the Key-ENC is > > > > (F995D0A069335C7DF42E590317FFEA6D) > > > > Where I am wrong or what I have forgot? > > Any help would be appreciated. > > > > Thanks in advance > > > > Kind Regards > > Agostino Sette > > > > > > > > _______________________________________________ > Globalplatform-developers mailing list > Glo...@li... > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: Sette A. <ago...@te...> - 2020-11-30 14:37:03
|
Hi, I am trying to develop my own SCP03 protocol and for this reason I cloned this git clone https://git.code.sf.net/p/globalplatform/git globalplatform-git as a starting point, first to understand how to proceed and then to check if what I did was correct. I verified almost everything except the Card Challenge, to be clear I would like to know how it is generated. As far a I know it should be generated as follows: Card challenge (8 bytes) (with PRNG): AES-CMAC (Key-ENC , 0x00 00 00 00 00 00 00 00 00 00 00 02 00 00 40 01 || context) "context": concat. of sequence counter (3 bytes) and AID of the application invoking the SecureChannel (5 to 16 bytes). Starting from the information on the file globalplatform/git/ci/master/tree/globalplatform/src/scp03Test.c I assumed that: 1. Key-ENC = {0xF9, 0x95, 0xD0, 0xA0, 0x69, 0x33, 0x5C, 0x7D, 0xF4, 0x2E, 0x59, 0x03, 0x17, 0xFF, 0xEA, 0x6D}; 2. Sequence counter = {0x00, 0x00, 0x15}; 3. AID = {0xA0, 0x01, 0x00, 0x01, 0x51, 0x41, 0x43, 0x4C}; The result card challenge, present on the same file into the "initializeUpdateResponse" is Card Challenge = {0xC4, 0x09, 0x32, 0xA6, 0xFE, 0xFE, 0xAE, 0xB2}; First of all, is all this correct? If yes, | context (00000000000000000000000200004001000015A00100015141434C) And the Key-ENC is (F995D0A069335C7DF42E590317FFEA6D) Where I am wrong or what I have forgot? Any help would be appreciated. Thanks in advance Kind Regards Agostino Sette |
|
From: Karsten O. <wid...@t-...> - 2019-08-24 19:35:06
|
Hi, I have added git to sourceforge: https://sourceforge.net/p/globalplatform/git/ci/master/tree/ SVN should be read only now. Feel free to fork it and create pull requests. The SCP03 MAC and encryption patches have been already applied. Your other patches not yet. Can you please integrate them into your fork? Karsten Am 23.08.2019 um 13:50 schrieb Klas Lindfors via Globalplatform-developers: > > It is. I started this approach already several times and wanted to > migrate to a different git hoster like Github, Bitbucket or gitlab > because I prefer their user interface, but I wanted to keep the > existing sourceforge repository for legacy reasons. Maybe just > using sourceforge's own git is an easier option. > > > For me hoster doesn't matter at all, anything that has some sort of > interface for contributing code makes me happier than svn. So my > preference would be for git on sourceforge, sounds like the least > amount of work while making the code more accessible. > > /klas > > > _______________________________________________ > Globalplatform-developers mailing list > Glo...@li... > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: Klas L. <kl...@yu...> - 2019-08-23 11:50:48
|
> > It is. I started this approach already several times and wanted to migrate > to a different git hoster like Github, Bitbucket or gitlab because I prefer > their user interface, but I wanted to keep the existing sourceforge > repository for legacy reasons. Maybe just using sourceforge's own git is an > easier option. > For me hoster doesn't matter at all, anything that has some sort of interface for contributing code makes me happier than svn. So my preference would be for git on sourceforge, sounds like the least amount of work while making the code more accessible. /klas |
|
From: Karsten O. <wid...@t-...> - 2019-08-23 11:06:49
|
Hi, Am 23.08.2019 um 09:23 schrieb Klas Lindfors: > > > > I have applied your patch. I have also added you to the AUTHORS > file if you don't mind. > > Ok, thanks. > > > Thanks for the other patches. I will continue with the other > patches later. > > Great! > > > Another approach would be to add you as a developer and you can > work in your own branch, before I merge it into the master trunk. > But patches are also fine. > > Up to you, I don't know how much more I'll be doing, probably adding > an unwrap to be able to verify responses properly. I guess migrating > to git is not an option? It is. I started this approach already several times and wanted to migrate to a different git hoster like Github, Bitbucket or gitlab because I prefer their user interface, but I wanted to keep the existing sourceforge repository for legacy reasons. Maybe just using sourceforge's own git is an easier option. > > /klas |
|
From: Klas L. <kl...@yu...> - 2019-08-23 07:24:04
|
I have applied your patch. I have also added you to the AUTHORS file if you > don't mind. > Ok, thanks. > Thanks for the other patches. I will continue with the other patches later. > Great! > Another approach would be to add you as a developer and you can work in > your own branch, before I merge it into the master trunk. But patches are > also fine. > Up to you, I don't know how much more I'll be doing, probably adding an unwrap to be able to verify responses properly. I guess migrating to git is not an option? /klas |
|
From: Karsten O. <wid...@t-...> - 2019-08-22 18:21:26
|
Hi Klas, I have applied your patch. I have also added you to the AUTHORS file if you don't mind. Thanks for the other patches. I will continue with the other patches later. Another approach would be to add you as a developer and you can work in your own branch, before I merge it into the master trunk. But patches are also fine. Karsten Am 22.08.2019 um 16:09 schrieb Klas Lindfors via Globalplatform-developers: > Hey, > > I have a couple more small patches for more scp03 support. If you want > to I can re-send the earlier large patch as broken up patches for each > specific thing. > > These are as follow: > scp03-fix-enc-iv.patch zeroes the IV before encrypting the counter > (this could just ues ECB instead since it's one block) > scp03-implement-get-key-data.patch implement scp03 parts in > get_key_data_field() > put-key-double-length.patch changes the template for put key to have > double lengths, as I understand the specification the length should be > duplicated, once for the key component block and once for the key > component value, I might've missunderstood this. > > Thanks! > > /klas > > On Thu, Aug 22, 2019 at 8:49 AM Klas Lindfors <kl...@yu... > <mailto:kl...@yu...>> wrote: > > Hello! > > thanks for the patch. I have started to fix the SCP03 mutual > authentication a couple days ago, not sure where I have left > off. Can you please describe the problem with the existing > code? I tried to summarize what I have found, is this correct? > > Sorry, should've provided more details with the patch, > > > * I see that the CMAC CLA byte is always set to 0x84, which > was incorrect. > > Yes, (as I read the spec) CLA on mac is supposed to always be 0x84 > disregarding whatever it actually is. > > * The EVP_EncryptUpdate is now not encrypting the message in > one step. > > Yeah, the previous code did EncryptUpdate in chunks of 8 which > means every second call just buffers the data, I replaced that > with one call to avoid having to care about sizes at all. > Additionally it only used 1-8 bytes of padding where AES needs > 1-16 bytes. > > * The padding size inthe wrap_command function is already > included in the encryptionLength and the wrappedLength > calculation can be simplified. > > Yeah, here I added checks of status from the AES functions to bail > out on failure and restructured the length calculations, > additionally the encrypted part from calculate_enc_cbc_SCP03() was > never moved into wrappedApduCommand. > > Have you checked if the R-MAC computation is correct? The > unwrap function is missing, so actually no response decryption > should work. I have not invested time to look into this, but > the patch does not contain any fixes for that? > > Yeah, R-MAC seems to validate correctly for me, I noted the > missing unwrap, no fix for that. > > I'm poking a bit at getting put_sc_key working with scp03 right now. > > Thanks! > > /klas > > > > _______________________________________________ > Globalplatform-developers mailing list > Glo...@li... > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: Klas L. <kl...@yu...> - 2019-08-22 14:10:21
|
Hey, I have a couple more small patches for more scp03 support. If you want to I can re-send the earlier large patch as broken up patches for each specific thing. These are as follow: scp03-fix-enc-iv.patch zeroes the IV before encrypting the counter (this could just ues ECB instead since it's one block) scp03-implement-get-key-data.patch implement scp03 parts in get_key_data_field() put-key-double-length.patch changes the template for put key to have double lengths, as I understand the specification the length should be duplicated, once for the key component block and once for the key component value, I might've missunderstood this. Thanks! /klas On Thu, Aug 22, 2019 at 8:49 AM Klas Lindfors <kl...@yu...> wrote: > Hello! > > thanks for the patch. I have started to fix the SCP03 mutual >> authentication a couple days ago, not sure where I have left off. Can you >> please describe the problem with the existing code? I tried to summarize >> what I have found, is this correct? >> > Sorry, should've provided more details with the patch, > > >> >> - I see that the CMAC CLA byte is always set to 0x84, which was >> incorrect. >> >> Yes, (as I read the spec) CLA on mac is supposed to always be 0x84 > disregarding whatever it actually is. > > >> - The EVP_EncryptUpdate is now not encrypting the message in one step. >> >> Yeah, the previous code did EncryptUpdate in chunks of 8 which means > every second call just buffers the data, I replaced that with one call to > avoid having to care about sizes at all. > Additionally it only used 1-8 bytes of padding where AES needs 1-16 bytes. > > >> - The padding size inthe wrap_command function is already included in >> the encryptionLength and the wrappedLength calculation can be simplified. >> >> Yeah, here I added checks of status from the AES functions to bail out on > failure and restructured the length calculations, additionally the > encrypted part from calculate_enc_cbc_SCP03() was never moved into > wrappedApduCommand. > > Have you checked if the R-MAC computation is correct? The unwrap function >> is missing, so actually no response decryption should work. I have not >> invested time to look into this, but the patch does not contain any fixes >> for that? >> > Yeah, R-MAC seems to validate correctly for me, I noted the missing > unwrap, no fix for that. > > I'm poking a bit at getting put_sc_key working with scp03 right now. > > Thanks! > > /klas > |
|
From: Klas L. <kl...@yu...> - 2019-08-22 07:13:35
|
Hello! thanks for the patch. I have started to fix the SCP03 mutual authentication > a couple days ago, not sure where I have left off. Can you please describe > the problem with the existing code? I tried to summarize what I have found, > is this correct? > Sorry, should've provided more details with the patch, > > - I see that the CMAC CLA byte is always set to 0x84, which was > incorrect. > > Yes, (as I read the spec) CLA on mac is supposed to always be 0x84 disregarding whatever it actually is. > - The EVP_EncryptUpdate is now not encrypting the message in one step. > > Yeah, the previous code did EncryptUpdate in chunks of 8 which means every second call just buffers the data, I replaced that with one call to avoid having to care about sizes at all. Additionally it only used 1-8 bytes of padding where AES needs 1-16 bytes. > - The padding size inthe wrap_command function is already included in > the encryptionLength and the wrappedLength calculation can be simplified. > > Yeah, here I added checks of status from the AES functions to bail out on failure and restructured the length calculations, additionally the encrypted part from calculate_enc_cbc_SCP03() was never moved into wrappedApduCommand. Have you checked if the R-MAC computation is correct? The unwrap function > is missing, so actually no response decryption should work. I have not > invested time to look into this, but the patch does not contain any fixes > for that? > Yeah, R-MAC seems to validate correctly for me, I noted the missing unwrap, no fix for that. I'm poking a bit at getting put_sc_key working with scp03 right now. Thanks! /klas |
|
From: Karsten O. <wid...@t-...> - 2019-08-21 15:29:42
|
Hi,
thanks for the patch. I have started to fix the SCP03 mutual
authentication a couple days ago, not sure where I have left off. Can
you please describe the problem with the existing code? I tried to
summarize what I have found, is this correct?
* I see that the CMAC CLA byte is always set to 0x84, which was incorrect.
* The EVP_EncryptUpdate is now not encrypting the message in one step.
* The padding size inthe wrap_command function is already included in
the encryptionLength and the wrappedLength calculation can be
simplified.
Have you checked if the R-MAC computation is correct? The unwrap
function is missing, so actually no response decryption should work. I
have not invested time to look into this, but the patch does not contain
any fixes for that?
Thanks,
Karsten
Am 21.08.2019 um 14:08 schrieb Klas Lindfors via Globalplatform-developers:
> Hello!
>
> I've been trying to use gpshell with a scp03 device and ran into some
> issues with how the encryption support is implemented. I'm attaching a
> patch that for me works for scp03 with 0x60 mode (c-dec, r-enc, c-mac,
> r-mac).
>
> Thanks!
>
> /klas
>
>
> _______________________________________________
> Globalplatform-developers mailing list
> Glo...@li...
> https://lists.sourceforge.net/lists/listinfo/globalplatform-developers
|
|
From: Klas L. <kl...@yu...> - 2019-08-21 12:36:11
|
Hello! I've been trying to use gpshell with a scp03 device and ran into some issues with how the encryption support is implemented. I'm attaching a patch that for me works for scp03 with 0x60 mode (c-dec, r-enc, c-mac, r-mac). Thanks! /klas |
|
From: Karsten O. <wid...@t-...> - 2017-03-06 16:45:55
|
Hi,
* Is it right? Can the JCRE invoke any method (in the API) of any
applet (even if the applet doesn't implements the RMI interface)
with the INVOKE APDU?
o If it can't invoke those methods with the INVOKE APDU, can it
invoke the methods with other APDU?
The JCRE is the runtime environment (RE!). It can do whatever it wants
with any applet, manipulate the byte code, the memory, everything. Of
course it can invoke also all methods. It can invoke it directly. It is
not necessary to use some external protocols. Like a Java Standard
edition can do it.
* How can I send an APDU to the JCRE directly and not to the selected
application?
AFAIR the JCRE offers some management functions like selecting an applet
and routing it. It can also act as the central command dispatcher. Maybe
also installation support is included. Look into the JCRE specification.
This should also answer all other questions.
* Can someone please give me an example of the INVOKE APDU?
Never used it. Not sure it this technology is still alive.
BR,
Karsten
Am 06.03.2017 um 15:30 schrieb גל ברק:
> Hello everyone,
>
> I'm not sure if this is the right spot to ask to following question.
> If not it will be awesome if someone can redirect me to other mailing
> list or forum.
>
> AFAIK, most if not all of the UICC are Java cards. Therefore, it has
> JCRE and JCVM.
>
> According to the Oracle's Java Card Platform Specification it is
> possible to invoke methods remotely using the INVOKE APDU if the
> applet has a remote interface.
>
> But I read (I'm sorry I don't remember where) that the JCRE can invoke
> any method of the Java card API of any applet.
>
> So my questions are :
>
> * Is it right? Can the JCRE invoke any method (in the API) of any
> applet (even if the applet doesn't implements the RMI interface)
> with the INVOKE APDU?
> o If it can't invoke those methods with the INVOKE APDU, can it
> invoke the methods with other APDU?
> * How can I send an APDU to the JCRE directly and not to the
> selected application?
> * Can someone please give me an example of the INVOKE APDU?
>
> Thanks for the responders! :)
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Globalplatform-developers mailing list
> Glo...@li...
> https://lists.sourceforge.net/lists/listinfo/globalplatform-developers
|
|
From: גל ב. <gal...@gm...> - 2017-03-06 14:30:19
|
Hello everyone,
I'm not sure if this is the right spot to ask to following question. If not
it will be awesome if someone can redirect me to other mailing list or
forum.
AFAIK, most if not all of the UICC are Java cards. Therefore, it has JCRE
and JCVM.
According to the Oracle's Java Card Platform Specification it is possible
to invoke methods remotely using the INVOKE APDU if the applet has a remote
interface.
But I read (I'm sorry I don't remember where) that the JCRE can invoke any
method of the Java card API of any applet.
So my questions are :
- Is it right? Can the JCRE invoke any method (in the API) of any applet
(even if the applet doesn't implements the RMI interface) with the INVOKE
APDU?
- If it can't invoke those methods with the INVOKE APDU, can it
invoke the methods with other APDU?
- How can I send an APDU to the JCRE directly and not to the selected
application?
- Can someone please give me an example of the INVOKE APDU?
Thanks for the responders! :)
|
|
From: Karsten O. <wid...@t-...> - 2017-02-07 17:19:23
|
Hi, 1. In theory, the GET DATA, MANAGE CHANNEL, SELECT and INITIALIZE UPDATE command can be executed by an off card entity without authentication? Yes. MANAGE CHANNEL, SELECT can always be executed without any security. GET DATA AFAIR also does not required a mutual authentication also when the card is personalized. Of course INITIALIZE UPDATE is also running on an insecure channel because it is the first command to establish a secure channel. 2. When sending a SMS-PP Data Download envelope, which is not formatted according to the 23.048 specification, which component (SD or app) process it? This depends on the UICC implementation. But if it is not formatted correctly the message will fail. Could have to format it correctly. To talk to your applet you can use the STORE DATA for PERSONALIZATION command structure and implement the org.globalplatform.Application interface in your applet. The STORE DATA command is wrapped in a SMS-PP then. 3. I got a strange behavior (in my opinion) - for every SMS I sent to my SIM card with an APDU without the 23.048 headers, I got the 9000 response. Why does it happening? Not within an ENVELOPE command? Maybe the command is matching a supported command, maybe the card is ignoring the unknown command, so a bug in the card OS. BR, Karsten Am 07.02.2017 um 16:36 schrieb גל ברק: > > > > > > > Hello Global Platform mail list, > > I'm a student and I'm studying about UICC and OTA. > > I got some questions and it will be awesome if someone would answer me : > > 1. In theory, the GET DATA, MANAGE CHANNEL, SELECT and INITIALIZE > UPDATE command can be executed by an off card entity without > authentication? > > 2. When sending a SMS-PP Data Download envelope, which is not > formatted according to the 23.048 specification, which component (SD > or app) process it? > > 3. I got a strange behavior (in my opinion) - for every SMS I sent to > my SIM card with an APDU without the 23.048 headers, I got the 9000 > response. Why does it happening? > > Many thanks in advance! > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > _______________________________________________ > Globalplatform-developers mailing list > Glo...@li... > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: גל ב. <gal...@gm...> - 2017-02-07 15:36:31
|
Hello Global Platform mail list, I'm a student and I'm studying about UICC and OTA. I got some questions and it will be awesome if someone would answer me : 1. In theory, the GET DATA, MANAGE CHANNEL, SELECT and INITIALIZE UPDATE command can be executed by an off card entity without authentication? 2. When sending a SMS-PP Data Download envelope, which is not formatted according to the 23.048 specification, which component (SD or app) process it? 3. I got a strange behavior (in my opinion) - for every SMS I sent to my SIM card with an APDU without the 23.048 headers, I got the 9000 response. Why does it happening? Many thanks in advance! |
|
From: Karsten O. <wid...@t-...> - 2016-10-28 00:21:57
|
Hi, thanks for the patch. I have a applied it in a slightly modified version. Check out the latest version from the trunk. Best Regards, Karsten Am 28.10.2016 um 00:52 schrieb Antonio Antonio: > Hi, > there is a memory leak in > https://sourceforge.net/p/globalplatform/code/HEAD/tree/trunk/gppcscconnectionplugin/src/gppcscconnectionplugin.c#l221 > > description: allocating cardInfo->librarySpecific without handling the > error case. > issue: if SCardConnect fails just go to end leaving > cardInfo->librarySpecific allocated > fix: suggest to add the green lines > regards > Antonio > cardInfo->librarySpecific = malloc(sizeof(PCSC_CARD_INFO_SPECIFIC)); > if (cardInfo->librarySpecific == NULL) { > OPGP_ERROR_CREATE_ERROR(status, ENOMEM, OPGP_stringify_error(ENOMEM)); > goto end; > } > pcscCardInfo = GET_PCSC_CARD_INFO_SPECIFIC_P(cardInfo); > result = SCardConnect( GET_SCARDCONTEXT(cardContext), > readerName, > SCARD_SHARE_SHARED, > protocol, > &(pcscCardInfo->cardHandle), > &activeProtocol ); > if(SCARD_S_SUCCESS!=result){ > /************** memory leak fix *****************/ > */if (cardInfo->librarySpecific != NULL) { > free(cardInfo->librarySpecific); cardInfo->librarySpecific = NULL; }/* > /************** memory leak fix - end ************/*//* > goto end; > } > > > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > > > _______________________________________________ > Globalplatform-developers mailing list > Glo...@li... > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: Antonio A. <tot...@gm...> - 2016-10-27 22:52:17
|
Hi, there is a memory leak in https://sourceforge.net/p/globalplatform/code/HEAD/tree/trunk/gppcscconnectionplugin/src/gppcscconnectionplugin.c#l221 description: allocating cardInfo->librarySpecific without handling the error case. issue: if SCardConnect fails just go to end leaving cardInfo->librarySpecific allocated fix: suggest to add the green lines regards Antonio cardInfo->librarySpecific = malloc(sizeof(PCSC_CARD_INFO_SPECIFIC)); if (cardInfo->librarySpecific == NULL) { OPGP_ERROR_CREATE_ERROR(status, ENOMEM, OPGP_stringify_error(ENOMEM)); goto end; } pcscCardInfo = GET_PCSC_CARD_INFO_SPECIFIC_P(cardInfo); result = SCardConnect( GET_SCARDCONTEXT(cardContext), readerName, SCARD_SHARE_SHARED, protocol, &(pcscCardInfo->cardHandle), &activeProtocol ); if ( SCARD_S_SUCCESS != result ) { /************** memory leak fix *****************/ * if (cardInfo->librarySpecific != NULL) { free(cardInfo->librarySpecific); cardInfo->librarySpecific = NULL; }* /************** memory leak fix - end ************/ goto end; } |
|
From: Greneche H. <gre...@gm...> - 2016-10-21 09:29:42
|
Hi I would like to participate to this project by adding some new features which will improve (in my sense) the use of GPShell. this is my first contribution to open source project so i need some advice. Can i start to develop new features now and proposed them to all or should I list new features for validation before ? Could I create a fork under github for this project ? Thanks for your response H.G |
|
From: Karsten O. <wid...@t-...> - 2016-09-13 22:18:07
|
Hi, yes, I'm reading this list. Thanks for the patch. I will submit it the the master. Thanks, Karsten Am 13.09.2016 um 09:28 schrieb Sebastien Lorquet: > Hello again, > > Looks like that I need is: > > OPGP_ERROR_STATUS calculate_enc_ecb_two_key_triple_des(BYTE key[16], BYTE > *message, int messageLength, BYTE *encryption, int *encryptionLength) > > I have found the svn repo, will send a patch. > > Sébastien Lorquet > > Le 12/09/2016 à 16:23, Sebastien Lorquet a écrit : >> Hello, >> >> Is there someone still reading this list? >> >> I would like to follow up on this >> >> https://sourceforge.net/p/globalplatform/mailman/message/31626315/ >> >> I have to use this and would like to say a word about this encryption. >> >> It would not be wise to encrypt the full data field, because it is not always >> the real requirement: >> >> - GP Data encryption does not define padding so encrypted data length always has >> to be a multiple of 8 bytes. >> >> - Sometimes data is sent via DGIs (kind of TLV tags) and ONLY the DGI CONTENTS >> has to be enecrypted. And more than one DGI can be sent in the same STORE DATA APDU. >> >> So the real need is not an extension of sendApdu but a new API in globalPlatform.h: >> >> >> OPGP_API OPGP_ERROR_STATUS GP211_encrypt_data(GP211_SECURITY_INFO *secInfo, >> PBYTE *buffer, DWORD bufferLength); >> >> OPGP_API OPGP_ERROR_STATUS GP211_decrypt_data(GP211_SECURITY_INFO *secInfo, >> PBYTE *buffer, DWORD bufferLength); >> >> Since there is no padding, the input and output buffers always have the same >> length (multiple of 8 bytes) the data can be processed in place. >> >> Only thing these functions have to do is encrypt/decrypt using triple-DES ECB >> with 2 keys. >> >> What is the proper development process to get this implemented and included in >> the next releases ? It is a valuable addition to GlobalPlatform library. >> >> Thanks for reading, >> > ------------------------------------------------------------------------------ > _______________________________________________ > Globalplatform-developers mailing list > Glo...@li... > https://lists.sourceforge.net/lists/listinfo/globalplatform-developers |
|
From: Sebastien L. <seb...@lo...> - 2016-09-13 08:04:40
|
Hello, Is there someone still reading this list? I would like to follow up on this https://sourceforge.net/p/globalplatform/mailman/message/31626315/ I have to use this and would like to say a word about this encryption. It would not be wise to encrypt the full data field, because it is not always the real requirement: - GP Data encryption does not define padding so encrypted data length always has to be a multiple of 8 bytes. - Sometimes data is sent via DGIs (kind of TLV tags) and ONLY the DGI CONTENTS has to be enecrypted. And more than one DGI can be sent in the same STORE DATA APDU. So the real need is not an extension of sendApdu but a new API in globalPlatform.h: OPGP_API OPGP_ERROR_STATUS GP211_encrypt_data(GP211_SECURITY_INFO *secInfo, PBYTE *buffer, DWORD bufferLength); OPGP_API OPGP_ERROR_STATUS GP211_decrypt_data(GP211_SECURITY_INFO *secInfo, PBYTE *buffer, DWORD bufferLength); Since there is no padding, the input and output buffers always have the same length (multiple of 8 bytes) the data can be processed in place. Only thing these functions have to do is encrypt/decrypt using triple-DES ECB with 2 keys. What is the proper development process to get this implemented and included in the next releases ? It is a valuable addition to GlobalPlatform library. Thanks for reading, -- Sébastien Lorquet |
|
From: Sebastien L. <seb...@lo...> - 2016-09-13 08:03:38
|
Hello again, Looks like that I need is: OPGP_ERROR_STATUS calculate_enc_ecb_two_key_triple_des(BYTE key[16], BYTE *message, int messageLength, BYTE *encryption, int *encryptionLength) I have found the svn repo, will send a patch. Sébastien Lorquet Le 12/09/2016 à 16:23, Sebastien Lorquet a écrit : > Hello, > > Is there someone still reading this list? > > I would like to follow up on this > > https://sourceforge.net/p/globalplatform/mailman/message/31626315/ > > I have to use this and would like to say a word about this encryption. > > It would not be wise to encrypt the full data field, because it is not always > the real requirement: > > - GP Data encryption does not define padding so encrypted data length always has > to be a multiple of 8 bytes. > > - Sometimes data is sent via DGIs (kind of TLV tags) and ONLY the DGI CONTENTS > has to be enecrypted. And more than one DGI can be sent in the same STORE DATA APDU. > > So the real need is not an extension of sendApdu but a new API in globalPlatform.h: > > > OPGP_API OPGP_ERROR_STATUS GP211_encrypt_data(GP211_SECURITY_INFO *secInfo, > PBYTE *buffer, DWORD bufferLength); > > OPGP_API OPGP_ERROR_STATUS GP211_decrypt_data(GP211_SECURITY_INFO *secInfo, > PBYTE *buffer, DWORD bufferLength); > > Since there is no padding, the input and output buffers always have the same > length (multiple of 8 bytes) the data can be processed in place. > > Only thing these functions have to do is encrypt/decrypt using triple-DES ECB > with 2 keys. > > What is the proper development process to get this implemented and included in > the next releases ? It is a valuable addition to GlobalPlatform library. > > Thanks for reading, > |
2 messages has been excluded from this view by a project administrator.