On Wed, May 27, 2009 at 11:53:53PM +0200, s.ferey wrote: > Jakob Bohm a écrit : > >> > >>according to GP 2.1.1, the load command does not throw 6A80, but the > >>install > >>command can. > >> > >well, it does.... > > of course it can! if the 'C4' tag is missing, if some lengths are > badly DER encoded, if a mandatory component is missing, if a required > package is not present in card, if a package-version is too high, ... > > >I hadn't know that, and I used those, so in response to your post > >I tried removing the -nvCodeLimit option, and then I got 6A80 > >after just a few bytes of code. The I tried upping the limit from > >8500 to 18500, and then more code got downloaded followed by a new > >error code (still during load): > > > >6985: Conditions of use not satisfied > > there is may be a different reason. Yeah, but which one...
> > >select -AID a0000000030000 > >open_sc -security 1 -keyind 0 -keyver 0 <GP ISK> > >delete -AID a00000000101 > ><-- 6A88 > >delete -AID a000000001 > ><-- 6A88 > > >install_for_load -pkgAID a000000001 -nvCodeLimit 8500 > >--> 80E602001705A00000000107A00000000300000006EF04C60221400000 > ><-- 009000 > > 80 E6 02 00 17 > 05 A000000001 -- package AID > 07 A0000000030000 -- card domain AID > 00 -- no File Data Hash > 06 -- load parameters length > EF 04 -- load parameters field > C6 02 2140 -- 8512 bytes of EEPROM required > 00 -- no Load Token > > if the "-nvCodeLimit" parameter is supposed to build the > load parameter field it is quite strange that it chooses > to change 8500d to 8512d. In GlobalPlatform.c, get_load_data() adds the size of the padding for DES CBC MAC (1..8 bytes 80 00... to make size multiple of 8) and the size of the CBC MAC itself (8 more bytes). The size calculation is not commented, so I am guessing at the purpose... . > > may be that value is too small, according empiric computation > (based on the begining of your CAP file present hereafter) > the on-card required size for your package is about 8300 bytes, > it is too close to not be a potential error, try with 9 or 10k. > > >load -file CardEdge.cap.transf > >file name CardEdge.cap.transf > >--> > >80E80000EFC4822CE801000FDECAFFED0102050C0005A00000000102001F000F001F000A00290242006C1F51000A03D50000068B00060000000004010004002904000107A0000000620101010107A0000000620102010107A0000000620201000107A000000062000103000A0106A00000000101009406006C00800314000D0404000500D4FFFF00B700F005C205DF05FE061D0647008300020001011100001A941B0A1B311BE81BF51C181C531C5D1C651C6E1C751C821C8D1C981CA11CB21CC3008300030001010D00001CDF1D371D591D9C1DAC1DBC1DDC1E901EA41EB51EC41ED21F36071F51000640188C002C1803880010 > ><-- 6A80 > > this APDU contains the directory, applet & import components, > according the last the applet requires: > > A0000000620101 vers. 1.0 ie javacard.framework JVC 2.1 > A0000000620102 vers. 1.1 ie javacard.security JVC 2.1.1 > A0000000620201 vers. 1.1 ie javacardx.crypto JVC 2.1.1 > A0000000620001 vers. 1.0 ie java.lang JVC 2.1 > Yes, I see the same numbers in the .jca file during build, I guess the two 2.1.0 version numbers mean that java.lang and javacard.framework did not add new exported identifies between 2.1.0 and 2.1.1 . But how do I determine if a card (any card) is supporting 2.1.0, 2.1.1 or 2.1.2, the JCSystem.getVersion() call only return the two first parts of the version. > >select -AID a0000000030000 > >open_sc -security 1 -keyind 0 -keyver 0 <ISK> > >install_for_load -pkgAID a000000001 -nvCodeLimit 12500 > >--> 80E602001705A00000000107A00000000300000006EF04C60230E00000 > ><-- 009000 > > ok, you did it. > > >load -file CardEdge.cap.transf > >file name CardEdge.cap.transf > >--> > >80E80000EFC4822CE801000FDECAFFED0102050C0005A00000000102001F000F001F000A00290242006C1F51000A03D50000068B00060000000004010004002904000107A0000000620101010107A0000000620102010107A0000000620201000107A000000062000103000A0106A00000000101009406006C00800314000D0404000500D4FFFF00B700F005C205DF05FE061D0647008300020001011100001A941B0A1B311BE81BF51C181C531C5D1C651C6E1C751C821C8D1C981CA11CB21CC3008300030001010D00001CDF1D371D591D9C1DAC1DBC1DDC1E901EA41EB51EC41ED21F36071F51000640188C002C1803880010 > ><-- 9000 > [all intermediate load steps OK] > >--> 80E880301C6810F0056811000568009004443103443006B444410544B410034B2000 > ><-- 6985 > > this is the very last APDU (P1 == 80) some other tests occur at this > stage, and I so think that this is a different error than the previous > 6A80 that was solved by an higher EEPROM space request. > > there is no obvious explanation for this '6985', the CAP file is valid > I succesfully load it into a CosmopolIC card. > Is CosmopolIC a 2.1.x card? Does CosmopolIC have the on-card byte code verifier? > I have no clue for Cyberflex, expect not using a Cyberflex. Well Cyberflex 32K is the easiest card to buy (amazingly, the Gemalto webstore is still not offering the 64K card, making it unavailable to end users like me!), and most other card makers are not offering blank cards as ready-to-buy for end users (for instance the highly certified Oberthur card has a dead US website and a main website which just has a blank area for the "enterprise solutions" usage class. Besides, Cyberflex e-gate 32K has been supported card #1 for the CardEdge applet for years, so just dropping support when something fails would be very bad for users who (like me) have already spent money based on past recommendations. -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any. _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
