Skip to main content
[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
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

Back to the top