[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [keyple-dev] Issue towards using UseCase4 & 10 with SAM-S1 E1
|
Dear Pierre Terree,
A bit of history:
One of our major partners expect our readers to be Calypso
compliant.
Although our readers are ISO complaint, we wanted to prove Calypso
compliance with an example/usecase.
We procured some test cards from ISRA. On top of the samples, ISRA
has not given us any other details (although several of our emails
to them went unanswered).
Then we sought help from one of our CNA contacts (Mr. TEIXEIRA
COSTA Ludovic) who has suggested us to check with UseCase 4 and
10.
We are new to Calypso ecosystem and with no info from ISRA we are
a bit lost as well towards the configuration that you seek.
We apologize if this is not going in the expected way.
May I ask you where should we try the KIF parameter 0x10h ? Is it
in initSecuritySetting()
?
If yes, As per the last support received from Keyple-Dev team,
my current code of the same is as follows:
private static void initSecuritySetting() {
LegacySam sam = selectSam(samReader);
symmetricCryptoSecuritySetting =
calypsoCardApiFactory.createSymmetricCryptoSecuritySetting(
LegacySamExtensionService.getInstance()
.getLegacySamApiFactory()
.createSymmetricCryptoCardTransactionManagerFactory(samReader, sam))
.assignDefaultKif(PERSONALIZATION, (byte) 0x21)
.assignDefaultKif(LOAD, (byte) 0x27)
.assignDefaultKif(DEBIT, (byte) 0x30)
.disableReadOnSessionOpening(); // Add this line
}
Kindly suggest.
By the way, wrt. the other email where you suggested to try with
AID 315449432E494341,
kindly note that there is no such AID in the test card. It
contains only 334D54522E494341 and 304554502E494341.
Attached is the Tool_CheckCardFileStructure-2.0.3.log for
reference.
Best regards,
Thillai Elayaraja S
![]()
![]() ![]()
|
Thillai
Elayaraja S |
| CTO |
| +91 72593 34534 |
| thillaielayaraja.s@xxxxxxxxxxx |
| |
| ELYCTIS
India Pte Ltd |
| Level 7, Mfar Greenheart |
| Manyata Tech Park |
| Bengaluru
560045 |
| INDIA |
On 07-07-2025 08:03 pm, Pierre Terree
wrote:
Hi
Thillai,
Before
running sessions between a Calypso test card and a Calypso
test SAM, it's important to know the configurations of both
the card and the SAM (especially when these are set up in a
rather obsolete way, making it difficult to retrieve this
information: a correctly personalized REV3 card should
return its KIF). Without it, it's like looking for a needle
in a haystack: the investigation can be time-consuming.
I think
the card you have contains several applications. And among
these applications, you're trying to select a
"Stored
Value" application! Is that what you're trying to do? If so,
please try again with a KIF parameter of 10h.
Dear Jean-Pierre,
Fine I will procure the test card + SAM from CNA and
continue testing.
Thank you for your support.
Best regards,
Thillai Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On 07-07-2025 07:09 pm, Jean-Pierre
Fortune wrote:
Unfortunately, it's not
possible to validate a transaction using an
emulated SAM in the way you're suggesting. This
would necessitate knowing the exact values of the
keys, and the entire security of Calypso
transactions relies precisely on the secrecy of
the keys stored by the SAM.
In your current situation, the
communication between the card and the SAM doesn't
seem to be the primary cause of the issue, at
least not at first glance. To be absolutely
certain, it would be ideal to have a card/SAM set
where we are completely assured of their
consistency. The symptoms you are encountering
strongly resemble a desynchronization in key
values. If the requested keys were not present in
the SAM, a different type of error would have been
reported.
Jean-Pierre Fortune
Keyple-Dev Team
Dear Jean-Pierre,
I tried commenting `prepareReadRecords(...)`
and the `6988` issue still persists.
By the way, is there a way to validate a
transaction using an emulated SAM in order to
isolate issues relating to Legacy SAM S1 E1
behavior ?
Best regards,
Thillai Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On 07-07-2025 06:33 pm,
Jean-Pierre Fortune wrote:
Unfortunately, I do not
have access to an equivalent set of cards
and SAMs to those provided by ISRA. This
makes it difficult to directly replicate
your setup here.
Before you receive the
test set from CNA, I suggest we try one
last approach. Could you please try
performing a transaction without any read
operations? This would involve commenting
out the `prepareReadRecords(...)` method
in your code.
While it's possible
this might lead to the same result, it's
worth exploring to see if it changes the
behavior of the `6988` error.
Jean-Pierre Fortune
Keyple-Dev Team
Dear Jean-Pierre,
I did the proposed change and the
`6988` issue still persists.
Best regards,
Thillai Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On 07-07-2025 04:13
pm, Jean-Pierre Fortune wrote:
Since we've
eliminated several common
causes, and considering the
SAM-S1 E1 is an older
generation, I have a suspicion
that the issue might stem from
its behavior during session
opening. It might not be
compatible or correctly handled
in your current setup.
Could you
please try an additional
modification in your code? I
would like to ask you to try
calling the
`disableReadOnSessionOpening()`
method on the
`SymmetricCryptoSecuritySetting`
object, immediately following
your `assignDefaultKif(...)`
calls. The updated code snippet
would look like this:
private static void
initSecuritySetting() {
LegacySam sam =
selectSam(samReader);
symmetricCryptoSecuritySetting
=
calypsoCardApiFactory
.createSymmetricCryptoSecuritySetting(
LegacySamExtensionService.getInstance()
.getLegacySamApiFactory()
.createSymmetricCryptoCardTransactionManagerFactory(samReader,
sam))
.assignDefaultKif(PERSONALIZATION,
(byte) 0x21)
.assignDefaultKif(LOAD, (byte)
0x27)
.assignDefaultKif(DEBIT,
(byte) 0x30)
.disableReadOnSessionOpening();
// Add this line
}
Please
implement this change for Use
Case 4 and let me know if it
resolves the `6988` error. If it
does, we can then apply the same
logic to Use Case 10.
Jean-Pierre
Fortune
Keyple-Dev Team
Dear Jean-Pierre,
Sorry for the
misunderstanding.
It is the part of the T=CL
protocol what is part of
ISO14443 Part-4 and it is
needed for the exchange.
Regarding your question:
We acquired the Calypso
Contactless card and the SAM
from ISRA who are one of the
members of CNA:
https://calypsonet.org/current-members/?alphabetical_filter=I
As I initially mentioned the
Calypso Contactless card
sample is labelled as
ST23ZR08 Calypso CD21 Rev
3.1 and
The SAM sample is labelled as
INTEROP vFF.E0.42 SAM-S1 E1.
We got two SAMs and 4
Contactless Card samples from
them and I tried with all
combinations with them; it
always yields to 6988 error.
Also tried them with Cardman
5321 (OMNIKEY reader) for the
Contactless and the uTrust
2700R (Identiv) for the
Contact without successful.
Infact it failed much earlier
with them and I can't get more
details.
Perhaps, do you have some
cards from ISRA to try on your
side which could give some
clue on the failure ?
Best regards,
Thillai Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On
07-07-2025 03:34 pm,
Jean-Pierre Fortune wrote:
My
apologies for the
confusion regarding the
`>` and `<`
characters. I was not
referring to those, but
rather to the `02` and
`03` bytes that appear
immediately after them,
as the very first byte
of the hexadecimal dump
in the contactless
reader captures (ex. 02 00 A4 04 00 08).
These bytes are not
visible in the SAM
exchanges.
These
bytes might be part of a
reader-specific
protocol. If they were
indeed being sent to the
card, the card would not
have responded in the
way it did, as it would
likely interpret them as
an invalid command or an
unexpected part of the
APDU.
This
leads me back to our
discussion about the
potential inconsistency
between the card and the
SAM. Could you please
provide more details
regarding the origin of
the card and the SAM you
are using? Specifically,
do you have any
assurance that they are
a consistent pair,
meaning they were
designed to work
together? Furthermore,
have you had success
using this specific card
and SAM combination in
other environments or
with other tools?
Understanding their
history and
compatibility will be
very helpful in
narrowing down the root
cause of the `6988`
error.
Dear Jean-Pierre,
The '> ' before CLA is
merely a debug
representation to
indicate command to
card. And the '< '
to indicate response
from card. Of course,
they are not part of
the card exchange.
So I assume that it
is related to mismatch
in card combinations.
We will soon procure
test cards from CNA
and start testing with
them.
Best regards,
Thillai Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar
Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On
07-07-2025 03:15 pm,
Jean-Pierre Fortune
wrote:
Thank you for sending over these new logs.
Upon reviewing the new logs, I've noticed an
additional
byte preceding
the CLA byte
in the
contactless
card exchanges
(02/03). Could
you please
clarify what
this first
byte
represents? If
it's merely an
indicator that
doesn't
directly
participate in
the card
exchanges, it
shouldn't be
influencing
the
transaction.
At first glance, I haven't detected any issues,
particularly
parasitic
exchanges,
that would
explain the
signature
error.
Another potential cause for this signature error could
be the
combination of
a production
card with a
test SAM, or
vice-versa. In
such
scenarios, the
key
identifiers
might be the
same, but the
actual key
values used
for
cryptographic
calculations
would differ,
leading to a
signature
mismatch.
Best regards,
Jean-Pierre
Fortune
Keyple-Dev Team
Dear
Jean-Pierre,
Here below
are the
low-captures
from our
Contactless
and Contact
reader:
Contact
reader
ATR : 3B 3F 96
00 80 5A 2A 80
E1 08 40 25 AE
11 E7 69 82 90
00
> 80 84 00
00 04
< 99 43 BB
C7 90 00
> 80 14 00
00 08 00 00 00
00 75 0D 26 4D
< 90 00
> 80 8A 00
FF 27 30 41 03
0D 09 B6 00 FF
41 1D 00
00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00
00 00 00 00
00 00 00 00 00
00 00 00
< 90 00
> 80 8E 00
00 04
< F3 D8 F3
EB 90 00
Contactless
reader
> 02 00 A4 04 00 08 30 45
54 50 2E 49 43
41 00
< 02 6F 22
84 08 30 45 54
50 2E 49 43 41
A5 16 BF
0C 13 C7 08
00 00 00 00 75
0D 26 4D 53 07
0A 2D
20 02 10 10
01 90 00
> 03 00 8A
0B A1 04 09 22
F8 B1 00
< 03 03 0D
0B F5 00 FF 41
1D 00 00 00 00
00 00 00
00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00
00 00 00 00
00 00 90 00
> 02 00 8E
00 00 04 00 6C
62 3F 00
< 02 69 88
Please note
that both of
them are two
different
sessions as
our debug
system does
not allow us
to capture
both
Contactless
and Contact
APDUs at the
same time.
Best
regards,
Thillai
Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar
Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On 04-07-2025 09:25 pm, Thillai Elayaraja S via
keyple-dev
wrote:
Dear
Jean-Pierre,
Yes, we are
the reader
manufacturer.
I will check
the low-level
traces on
Monday.
Thanks for
your support
so far.
Best
regards,
Thillai
Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar
Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On 04-07-2025 09:21 pm, Jean-Pierre Fortune wrote:
Hi Thillai,
The
DIGEST_INIT
[6A83] issue
being
resolved, it
is clear that
the initial
missing
configuration
for the
default KIFs
in Use Case 4,
already
present in Use
Case 10, was
indeed the
root cause of
that
particular
problem.
We now seem to
be back to the
issue of the
card's
verification
of the
signature
generated by
the SAM
failing,
indicated by
the `6988`
status word.
If we are
certain that
no APDU
commands other
than those
visible in the
logs were sent
to either the
card or the
SAM, then this
situation
might suggest
a potential
inconsistency
between the
SAM and the
card. However,
I assume that
you are using
a consistent
set of SAM and
card samples.
Given that you
are the
manufacturer
of the reader,
do you have
any means to
trace the
low-level
exchanges
directly from
the reader(s)
themselves? It
would be
highly
beneficial to
compare these
low-level
traces with
the APDU
commands we
are seeing in
the logs. This
could help us
pinpoint any
discrepancies
or unexpected
behaviors that
might be
occurring at
the physical
communication
level.
Best regards,
Jean-Pierre
Fortune
Keyple-Dev
Team
Dear
Jean-Pierre,
I did the
change and now
the
`DIGEST_INIT
[6A83]` issue
is resolved.
Now I have
the `6988 `
issue. Log
attached for
Use Case 4.
Once this is
solved, I will
check with Use
Case 10.
Best
regards,
Thillai
Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar
Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On 04-07-2025 08:13 pm, Jean-Pierre Fortune wrote:
The error
`6A83` in
response to
`DIGEST_INIT`
indicates that
the SAM, which
is being
requested to
perform
calculations
with the key
(KIF=FF,
KVC=41), does
not possess
this specific
key.
My advice to
use `FF` as a
KIF was a
misinterpretation,
as this value
is actually
reserved to
indicate an
*unknown* KIF
and should not
be used as a
valid key
reference.
Instead, I
suggest
retrying Use
Case 4 with
the following
configuration,
which
corresponds to
the values
commonly used
for the three
standard KIFs:
.assignDefaultKif(PERSONALIZATION,
(byte) 0x21)
.assignDefaultKif(LOAD, (byte) 0x27)
.assignDefaultKif(DEBIT, (byte) 0x30)
I will also
check with
other members
of the Calypso
team to better
understand the
content of the
JSON file
describing the
card’s
structure and
keys.
Jean-Pierre Fortune
Keyple-Dev
Team
Dear
Jean-Pierre,
I did the
change and the
issue
"Unauthorized
key error" is
resolved.
Now I have
DIGEST_INIT
[6A83] issue.
Logs
attached.
Enabled DEBUG
traces for Use
Case 10 too.
Best
regards,
Thillai
Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar
Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On 04-07-2025 06:29 pm, Jean-Pierre Fortune wrote:
Upon closer examination of the logs you sent, it
appears that
the code
execution flow
in both cases
is not the
same, and the
errors
encountered
are of a
different
nature.
My previous message was based on Use Case 10, which
seems to
correspond to
a transaction
involving two
readings of
the SFI=14h
file. However,
the log for
this case does
not display
DEBUG level
traces, which
would be very
helpful for a
more in-depth
analysis.
On the other hand, the log for Use Case 4 does show
DEBUG traces,
but here the
transaction
concludes with
an
"Unauthorized
key error."
This specific
error suggests
that the card
you are using
requires a
particular
configuration
to specify the
key KIF value
that is not
provided by
this
particular
card.
Based on the JSON file generated by the card analysis
tool, the KIF
value to be
used for this
AID is 0xFF.
In the context
of the Use
Case 4 code,
this would
translate to
an adjustment
within the
`initSecuritySetting()`
method,
similar to the
following:
private
static void
initSecuritySetting()
{
LegacySam
sam =
selectSam(samReader);
symmetricCryptoSecuritySetting
=
.createSymmetricCryptoSecuritySetting(
LegacySamExtensionService.getInstance()
.getLegacySamApiFactory()
.createSymmetricCryptoCardTransactionManagerFactory(samReader,
sam))
.assignDefaultKif(PERSONALIZATION,
(byte) 0xFF)
.assignDefaultKif(LOAD,
(byte) 0xFF)
.assignDefaultKif(DEBIT,
(byte) 0xFF);
Could you please try implementing this change in your
Use Case 4
code and
observe if it
resolves the
"Unauthorized
key error"?
Regarding use case 10, I would need more logs to help
you. But the
previous
configuration
with 0xFF
should also
apply here!
Dear
Jean-Pierre,
I tried
that and the
status (logs
shared in
previous
email) remains
the same:
C:\Windows\System32>sc
query
ScDeviceEnum
SERVICE_NAME:
ScDeviceEnum
TYPE
: 30 WIN32
STATE
: 1 STOPPED
WIN32_EXIT_CODE
: 0 (0x0)
SERVICE_EXIT_CODE
: 0 (0x0)
CHECKPOINT
: 0x0
WAIT_HINT
: 0x0
C:\Windows\System32>sc query CertPropSvc
SERVICE_NAME:
CertPropSvc
TYPE
: 20
WIN32_SHARE_PROCESS
STATE
: 1 STOPPED
WIN32_EXIT_CODE
: 1077
(0x435)
SERVICE_EXIT_CODE
: 0 (0x0)
CHECKPOINT
: 0x0
WAIT_HINT
: 0x0
C:\Windows\System32>sc config ScDeviceEnum start= disabled
[SC]
ChangeServiceConfig
SUCCESS
C:\Windows\System32>sc config CertPropSvc start= disabled
[SC]
ChangeServiceConfig
SUCCESS
Best
regards,
Thillai Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar
Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On 04-07-2025 05:33 pm, Jean-Pierre Fortune wrote:
This is a
significant
step forward!
The fact that
the secure
transaction
now goes all
the way
through is
excellent
news, as it
confirms good
communication
between your
reader, the
card, and the
SAM.
The final
error you're
encountering,
related to the
card's
verification
of the
signature
calculated by
the SAM, isn't
necessarily
directly
related to the
software
you're
running.
Most
frequently,
this problem
is linked to
interference
from Windows
smart card
services.
Specifically,
these are the
"Smart Card
Device
Enumeration
Service" (ScDeviceEnum) and the
"Certificate
Propagation
Service" (CertPropSvc). These services can
unfortunately
insert
invisible
exchanges with
the card or
the SAM,
causing the
cryptographic
calculations
to fail.
Could you
please try
disabling
these services
and let us
know if this
resolves the
issue?
To check
their status
before
disabling
them, you can
run the
following
commands in an
elevated Command Prompt
(Run as
Administrator):
sc query ScDeviceEnum
sc query CertPropSvc
This will
tell you
whether the
services are
currently
running. You
can also check
their startup
configuration
using:
sc qc ScDeviceEnum
sc qc CertPropSvc
To stop and
disable the
services
(again, in an
elevated
Command
Prompt), use:
sc stop ScDeviceEnum
sc config ScDeviceEnum start= disabled
sc stop CertPropSvc
sc config CertPropSvc start= disabled
We remain at your disposal for any further assistance.
Best regards,
Jean-Pierre
Fortune
Keyple-Dev
Team
Dear
Jean-Pierre,
I tried to
adapt both of
the examples
and attached
the Console
log received.
The
adaptation I
made was to
change the AID
to
"304554502E494341"
and the
SFI_ENVIRONMENT_AND_HOLDER
to 0x14
(with
UseCase10 used
SFI_CONTRACTS
as 0x15 but
unsure about
SFI_EVENTS_LOG
and
SFI_CONTRACT_LIST)
With that
it seems it
has progressed
a bit more in
either of the
examples but I
can't make it
work to see it
complete
gracefully.
It seems to
me that the
card is not
personalized
on my side.
Could you
confirm and
guide me on
the right
example to
start with ?
By the way,
it is my first
few days
working with
Calypso:
I see that
although a bit
of learning
curve is
required
(atleast for
me), Keyple is
making it far
more easier
than I
thought. Kudos
to all of you.
Best
regards,
Thillai Elayaraja S
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar
Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
On 04-07-2025 01:27 pm, Jean-Pierre Fortune wrote:
Hi Thillai,
Thanks for
reaching out
to the
Keyple-Dev
community and
for providing
these detailed
logs.
Based on
our analysis
of the logs,
the issue
doesn't seem
to be at the
physical
communication
level. The
exchanges
between your
reader and the
card appear to
be correct.
The errors
you're
encountering
are happening
at a higher,
application
command level.
Specifically,
in the log for
UseCase10, the
OPEN_SECURE_SESSION command fails
with a
6A82 status word, which means
"File not
found". This
command is
trying to read
record 1 of
the file
located by SFI
(Short File
Identifier)
0x06.
However,
the JSON file
generated by
the card
analysis tool
shows that a
file with
SFI=0x06 does
not actually
exist on your
card sample.
This mismatch
is the direct
cause of the
error.
This leads
us to the main
question: have
you adapted
the APDU
commands in
the examples
to match the
specific file
structure of
the card you
are using?
It seems
likely that
adapting the
SFI and record
parameters
within the
commands to
align with
your card's
actual file
system should
resolve the
issue. The
good news is
that this
suggests your
reader is
indeed capable
of handling
the low-level
Calypso
protocol
correctly.
Let us know
if adjusting
the commands
solves the
problem.
Best
regards,
Jean-Pierre
Fortune
Keyple-Dev
Team
Dear
Keyple-Dev
team,
Good day!
I'm Thillai
Elayaraja, CTO
of ELYCTIS.
Currently I'm
evaluating
Calypso
support with
our PC/SC
readers with a
Calypso card
sample + SAM
acquired from
ISRA.
The Calypso
card sample is
labelled as ST23ZR08
Calypso CD21
Rev 3.1
and
The SAM sample
is labelled as
INTEROP
vFF.E0.42
SAM-S1 E1.
With them I
tried the
examples
UseCase4 and
UseCase10 from
Keyple but
encounter
issues
detailed
below. I tried
to adapt those
examples to
use the reader
regex, Card
AID (taken
from the Card
Configuration
Audit tool)
and also
changed the
LegacySamUtil.buildPowerOnDataFilter()
to use
LegacySam.ProductType.SAM_S1E1,
with vain. I
got to know
from one of
the CNA
contacts to
seek help from
the Keyple-Dev
community and
that's where
here I'am with
the details
given below:
Regarding
the examples:
-
UseCase4_CardAuthentication:
Attached the UseCase4_CardAuthentication.log
for reference.
For info, the
code stopped
at
processCommands as below:
-
UseCase10_SessionTrace_TN313:
Attached the UseCase10_SessionTrace_TN313.log
for reference.
For info, the
log ends with
the following
error:
[11:01:01:138]
[pool-1-thread-1]
[ERROR]
CardReaderObserver
-
[Transaction failed with exception: A card command
error occurred
while
processing
responses to
card commands:
OPEN_SECURE_SESSION
Transaction
audit JSON
data:
{"targetSmartCard":{"selectApplicationResponse":{"apdu":"6F228408334D54522E494341A516BF0C13C70800000000750D264E53070A2D20021010019000","statusWord":"9000"},"isExtendedModeSupported":false,"isRatificationOnDeselectSupported":true,"isSvFeatureAvailable":false,"isPinFeatureAvailable":false,"isPkiModeSupported":false,"isDfInvalidated":false,"calypsoCardClass":"ISO","calypsoSerialNumber":"00000000750D264E","startupInfo":"0A2D2002101001","productType":"PRIME_REVISION_3","dfName":"334D54522E494341","modificationsCounterMax":"01AE","isModificationCounterInBytes":true,"files":[],"filesBackup":[],"svLastTNum":"00","svLastTNumBackup":"00","isHce":false,"svKvc":"00","applicationSubType":"02","applicationType":"20","sessionModification":"0A","payloadCapacity":"FA","isCounterValuePostponed":false,"isLegacyCase1":false},"apdus":["008A0B3904AF711A9400","6A82"]}
[11:01:01:138]
[pool-1-thread-1] [INFO] ObservableLocalReaderAdapter - Reader [ELYCTIS
CL reader
FFFFFFFF0000
0] starts card
removal
sequence
Regarding Card Configuration Audit tools:
-
Attached the Tool_AnalyzeCardFileStructure-2.0.3.log
and the
generated
20250626_CardData_1963796046.json for reference.
-
Attached the Tool_CheckCardFileStructure-2.0.3.log
for reference.
With these
logs and info,
could you help
if I need to
adapt the
examples
further to
verify the
intended
use-cases ?
And can we
"tentatively"
say if our
reader is
capable to
support
Calypso
transactions ?
Thanking you.
With best
regards,
Thillai
Elayaraja S
P S : Soon
we will try to
procure the
test kits from
CNA to
validate our
readers with
all usecases
and with the
demonstrator
app.
--
|
![Image supprimée par l'expéditeur.]()
![Image supprimée par l'expéditeur.]() ![Image supprimée par l'expéditeur.]()
|
Thillai
Elayaraja S
|
|
CTO
|
|
+91
72593 34534
|
|
thillaielayaraja.s@xxxxxxxxxxx
|
|
|
|
ELYCTIS
India Pte Ltd
|
|
Level
7, Mfar
Greenheart
|
|
Manyata
Tech Park
|
|
Bengaluru
560045
|
|
INDIA
|
_______________________________________________
keyple-dev
mailing list
keyple-dev@xxxxxxxxxxx
To unsubscribe
from this
list, visit
https://www.eclipse.org/mailman/listinfo/keyple-dev
_______________________________________________
keyple-dev mailing list
keyple-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/keyple-dev
_______________________________________________
keyple-dev
mailing list
keyple-dev@xxxxxxxxxxx
To unsubscribe
from this
list, visit
https://www.eclipse.org/mailman/listinfo/keyple-dev
PS D:\WORKSPACE\support\calypso\cna-tool-card-analyzer> java -jar .\Tool_AnalyzeCardFileStructure-2.0.3.jar ".*"
[18:58:17:888] [main] [INFO] SmartCardServiceAdapter - Register plugin [PcscPlugin]
[18:58:17:904] [main] [INFO] PcscPluginWinAdapter - java.specification.version = 9.0. Reflexivity is allowed.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.eclipse.keyple.plugin.pcsc.PcscPluginWinAdapter (file:/D:/WORKSPACE/support/calypso/cna-tool-card-analyzer/Tool_AnalyzeCardFileStructure-2.0.3.jar) to field sun.security.smartcardio.PCSCTerminals.contextId
WARNING: Please consider reporting this to the maintainers of org.eclipse.keyple.plugin.pcsc.PcscPluginWinAdapter
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
[18:58:17:952] [main] [INFO] ToolUtils - Card reader, plugin; PcscPlugin, name: ELYCTIS CL reader FFFFFFFF0000 0
[18:58:17:952] [main] [INFO] Tool_AnalyzeCardFileStructure - = Card Reader NAME = ELYCTIS CL reader FFFFFFFF0000 0
[18:58:18:630] [main] [INFO] Tool_AnalyzeCardFileStructure - ========================================================================================================
[18:58:18:630] [main] [INFO] Tool_AnalyzeCardFileStructure - = Id:: 20250626_CardData_1963796046.json
[18:58:18:630] [main] [INFO] Tool_AnalyzeCardFileStructure - = Date:: 26/06/2025 18:58:18
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Version:: 002
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Software:: Calypso Card Analyzer
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Traceability:: 10C0CAA071E97536001546317014136153AC4F000607011C3D000000000000000000318400000000C853ACB04F01FE01FE0000000000002D100100000000000000040071000000000000750D264E0250184201322141000A0000000000000000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - ========================================================================================================
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | AID | LID | KVC1 | KVC2 | KVC3 | KIF1 | KIF2 | KIF3 | G0 | G1 | G2 | G3 |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | 334D54522E494341 | 0000 | 41 | 41 | 41 | 00 | 00 | 00 | -- | -- | NN | NN |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - ========================================================================================================
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = FCI:: 6F228408334D54522E494341A516BF0C13C70800000000750D264E53070A2D20021010019000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Serial Number:: 00000000750D264E (1963796046)
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Transaction Counter:: 0
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Revision:: PRIME_REVISION_3
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Session Buffer Size:: 430 bytes
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Platform (Chip Type):: 2D
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Issuer:: STMicroelectronics (10)
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Software Version:: 10.01
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Application Type:: 20
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Application Subtype:: 02
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = DF Status:: 00
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - ========================================================================================================
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | LID | Type | SID | #R | Size | G0 | G1 | G2 | G3 | DRef |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - ----------------------------------------------------------
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | 0200 | Lin | 02 | 01 | 0029 | AA | NN | -- | NN| 0000 |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #01:00000000000000080071330200000000750D264E025018000132214300
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | 0300 | Lin | 03 | 01 | 0029 | PN | -- | NN | NN| 0000 |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | 0400 | Lin | 04 | 01 | 0008 | AA | -- | NN | NN| 0000 |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #01:334D54522E494341
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | 1000 | Lin | 05 | 04 | 0029 | AA | -- | -- | NN| 0000 |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #01:0000000000000000000000000000000000000000000000000000000000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #02:0000000000000000000000000000000000000000000000000000000000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #03:0000000000000000000000000000000000000000000000000000000000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #04:0000000000000000000000000000000000000000000000000000000000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - ========================================================================================================
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | AID | LID | KVC1 | KVC2 | KVC3 | KIF1 | KIF2 | KIF3 | G0 | G1 | G2 | G3 |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | 304554502E494341 | 1000 | 41 | 41 | 41 | FF | FF | FF | S1 | S3 | NN | NN |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - ========================================================================================================
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = FCI:: 6F228408304554502E494341A516BF0C13C70800000000750D264E53070A2D20021010019000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Serial Number:: 00000000750D264E (1963796046)
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Transaction Counter:: 0
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Revision:: PRIME_REVISION_3
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Session Buffer Size:: 430 bytes
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Platform (Chip Type):: 2D
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Issuer:: STMicroelectronics (10)
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Software Version:: 10.01
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Application Type:: 20
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = Application Subtype:: 02
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - = DF Status:: 00
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - ========================================================================================================
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | LID | Type | SID | #R | Size | G0 | G1 | G2 | G3 | DRef |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - ----------------------------------------------------------
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | 1014 | Cycl | 14 | 01 | 0029 | AA | NN | NN | NN| 0000 |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #01:0000000000000000000000000000000000000000000000000000000000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - | 1015 | Cycl | 15 | 03 | 0029 | AA | NN | NN | NN| 0000 |
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #01:0000000000000000000000000000000000000000000000000000000000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #02:0000000000000000000000000000000000000000000000000000000000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - + #03:0000000000000000000000000000000000000000000000000000000000
[18:58:18:634] [main] [INFO] Tool_AnalyzeCardFileStructure - ========================================================================================================
