Re: [keyple-dev] Issue towards using UseCase4 & 10 with SAM-S1 E1

[Jean-Pierre Fortune <jean-pierre.fortune@xxxxxxxxx>]

Hi Thillai,

Following some additional testing, we have identified a compatibility issue in our library.

It appears that a misconfiguration in our build process, although targeting Java 8, causes an incompatibility when the library is run with a Java 8 environment (JRE 8), leading to a NoSuchMethodError. This issue had not been detected until now because our internal tests are typically performed on more recent Java versions (such as 11 or 17), where this problem does not occur.

We are currently preparing a new version of the library to permanently fix this.

While we work on this update, if you plan to run the application on a JRE 8, we recommend as a workaround that you use a more recent runtime environment, such as Java 11 or a later version.

Best regards,

-- 

Jean-Pierre Fortune

Le lun. 21 juil. 2025 à 09:01, Thillai Elayaraja S via keyple-dev <keyple-dev@xxxxxxxxxxx> a écrit :

Dear Keyple-Dev team,

Update: I started testing few usecase examples with certain cards and the respective logs are attached for reference.

It seems, we encounter an issue with UseCase16_PkiModeSession. Could you please clarify on the same?

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 16-07-2025 04:35 pm, Thillai Elayaraja S via keyple-dev wrote:

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.

De : Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx>
Date : lundi, 7 juillet 2025 à 17:11
À : Pierre Terree <pierre.terree@xxxxxxxxxxxxxx>, keyple developer discussions <keyple-dev@xxxxxxxxxxx>
Cc : Jean-Pierre Fortune <jean-pierre.fortune@xxxxxxxxx>
Objet : 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.

 

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

	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:

Hi Thillai,

 

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.

 

Best regards,

Jean-Pierre Fortune
Keyple-Dev Team

 

 

 

Le lun. 7 juil. 2025 à 15:32, Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx> a écrit :

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

	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:

Hi Thillai,

 

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.

 

Best regards,

 

Jean-Pierre Fortune
Keyple-Dev Team

 

 

Le lun. 7 juil. 2025 à 14:24, Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx> a écrit :

Dear Jean-Pierre,

I did the proposed change and the `6988` issue still persists.

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 04:13 pm, Jean-Pierre Fortune wrote:

Hi Thillai,

 

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.

 

Best regards,

Jean-Pierre Fortune
Keyple-Dev Team

 

 

Le lun. 7 juil. 2025 à 12:24, Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx> a écrit :

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

	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:

Hi Thillai,

 

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.

 

Best regards,

Jean-Pierre Fortune

Keyple-Dev Team

 

 

 

Le lun. 7 juil. 2025 à 11:55, Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx> a écrit :

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

	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:

Hi Thillai,

 

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

 

Le lun. 7 juil. 2025 à 11:24, Thillai Elayaraja S via keyple-dev <keyple-dev@xxxxxxxxxxx> a écrit :

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

 

Le ven. 4 juil. 2025 à 17:16, Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx> a écrit :

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

 

Le ven. 4 juil. 2025 à 15:54, Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx> a écrit :

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

 

 

Le ven. 4 juil. 2025 à 14:16, Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx> a écrit :

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

 

Le ven. 4 juil. 2025 à 13:05, Thillai Elayaraja S <thillaielayaraja.s@xxxxxxxxxxx> a écrit :

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

 

Le ven. 4 juil. 2025 à 09:32, Thillai Elayaraja S via keyple-dev <keyple-dev@xxxxxxxxxxx> a écrit :

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.

--

	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

_______________________________________________
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