[
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 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
|
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
|
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
|
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:
Hi Thillai,
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.
Best regards,
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
|
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:
Hi Thillai,
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 =
calypsoCardApiFactory
.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!
Best regards,
Jean-Pierre Fortune
Keyple-Dev
Team
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
|
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:
Hi Thillai,
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
|
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.
_______________________________________________
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