[
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 Keyple-Dev team,
We have acquired the attached Calypso test cards.
May I know if there is a defined test procedure or UseCase
examples to validate our readers for Calypso compliance?
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 08-07-2025 02:43 pm, Thillai
Elayaraja S via keyple-dev wrote:
Dear Pierre Terree,
Thank you for the last info.
It seems that the Use Case 4 and 10 are working now with the
proposed change.
I have attached the respective logs for reference.
If there is nothing more to test with these cards, we will
continue ordering the test kits and continue with them.
Thanks for your support.
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:57 pm, Pierre Terree
wrote:
Don't
worry, we'll help you. I propose one last try with the
card you've got
OK
keep the current AID, but change this parameter: .assignDefaultKif(DEBIT,
(byte) 0x10)
→ If
you're lucky, you'll be able to open and close a secure
session.
I'll
be honest, you won't be able to do many more tests with
this card: I think this card is personalized in a
"non-compliant" way 🤯.
I
understand you're planning to order an official test kit
from CNA: then it'll be easier for you to test.
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
|
![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 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
_______________________________________________
keyple-dev mailing list
keyple-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/keyple-dev
Attachment:
Calypso_test_cards.jpg
Description: JPEG image
