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.
De :
keyple-dev <keyple-dev-bounces@xxxxxxxxxxx> de la part de Thillai Elayaraja S via keyple-dev <keyple-dev@xxxxxxxxxxx>
Date : lundi, 7 juillet 2025 à 15:44
À : Jean-Pierre Fortune <jean-pierre.fortune@xxxxxxxxx>
Cc : Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx>, keyple developer discussions <keyple-dev@xxxxxxxxxxx>
Objet : Re: [keyple-dev] Issue towards using UseCase4 & 10 with SAM-S1 E1
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
|
