| Re: [keyple-dev] Issue towards using UseCase4 & 10 with SAM-S1 E1 |
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 |
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=IAs 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 FortuneKeyple-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 88Please 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 FortuneKeyple-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 CertPropSvcThis will tell you whether the services are currently running. You can also check their startup configuration using:
sc qc ScDeviceEnum sc qc CertPropSvcTo 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= disabledWe 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, theOPEN_SECURE_SESSIONcommand fails with a6A82status 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:
Regarding Card Configuration Audit tools:
- 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
- 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
