I hope this post finds you all well. Today, I would like to address a specific topic that has been causing some challenges for users of Red Hat systems who are working with Infineon devices. We have identified certain issues with kernel modules and drivers for Infineon devices, and I would like to open up a discussion to gather insights, experiences, and possible solutions from the community.

Here are some of the key points related to this topic:

1. Identification of the Issue: Users have reported difficulties in properly configuring and utilizing Infineon devices on Red Hat systems due to problems with kernel modules and drivers. These issues have resulted in limited functionality, poor performance, or even complete failure to recognize the devices.

2. Affected Infineon Devices: While the issue is not limited to a specific device, it has been observed across various Infineon hardware components such as security controllers, TPMs (Trusted Platform Modules), smart card readers, and other related devices.

3. Red Hat System Versions: The issues have been reported on different versions of Red Hat systems, including both the Enterprise Linux (RHEL) distribution and the community-driven Fedora project. It is important to note that these problems may not be exclusive to Red Hat, but it is the focus of this discussion.

4. Possible Causes: The problems may stem from compatibility issues between Infineon device firmware, kernel versions, and associated drivers. It is also plausible that some configuration settings or dependencies need to be properly addressed to ensure seamless integration.

Given the importance of Infineon devices in various fields such as security, encryption, and authentication, it is crucial to establish a robust and reliable solution for Red Hat users. Therefore, I invite all community members who have encountered or have insights on these issues to participate in this discussion.

Show Less

Hi everyone,

I recently started working with an OPTIGA Trust X Evaluation Kit in order to gain experience with OPTIGA Trust products. I followed every step described in the Get-Started guide, which I found here:

https://github.com/Infineon/getstarted-optiga-trust-x/wiki

Everything works fine, I am able to debug the program with DAVE, see the outputs with the UART etc.

I only seem to have an issue with the initialization. Indeed, the basic main function given in the GitHub repository is supposed to print several messages to show different uses of the Trust X, but I am only able to get the "Device closed" message at the end of the function.

After a bit of debugging, I found that I had an issue returning from the TransceiveAPDU function, being called by the GetMaxCommsBuffer function.

Indeed, I receive an error code 0x80010001 which according to the documentation is due to an invalid OID.

From what I can read in the code, the OID to read the maximum communication buffer size is 0xE0C6, which is consistent with the OPTIGA Trust X1 Solution Reference Manual. 

I haven't configured anything particular so do you have any idea of why this OID could be considered invalid ? I am fairly new to that platform and I can't figure out what is wrong with this OID.

I would be very grateful for your help !

Best regards,

Maxime MARTIN

Show Less

Hi,
I am planning to use Optiga TrustX module in my project. One requirement in that project is to comply with the 802.1AR standard (Secure Identity Key).
I know that TPM modules are for that purpose, but I am not sure about Trust X. what is the exact difference between them? Why isn't optiga trust X marked TCG TPM? I checked the documentation but the only remark about the difference is that TrustX is for embedded systems but TPM modules are for more powerful PC or linux-based systems.
I appreciate if you can share your thoughts about TrustX for 802.1AR compatibility.

Best regards,
Vedat Show Less

Hi,
I am playing this example from NordicSemi here:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.3.0%2Fifx_optiga_custom_example.html&cp=5_1_4_3_1_2

In this example, there is a test regarding key derivation as:

static void uc_key_derivation(void)
{
    optiga_lib_status_t optiga_lib_status;
    uint8_t  info[100] = { 0 };
    uint16_t info_len  = 100;
    uint16_t oid               = 0xF1D0;
    uint8_t  shared_secret[64] = { 0 };

    // Check if key derivation is supported (OPTIGA Trust X after version 1.20.1048)
    optiga_lib_status = optiga_util_read_data(0xE0C2, 0, info, &info_len);
    DEMO_OPTIGA_ERROR_CHECK(optiga_lib_status);

    if (info[25] == 0x10 && info[26] == 0x48) // !!!! THIS CONDITION RETURNS TRUE
    {
        NRF_LOG_INFO("Key derivation not supported!\r\n");
        NRF_LOG_FLUSH();
        return;
    }

As I understand, it checks the fw version of the OptigaX for if key derivation is supported or not. According to the reply of the TrustX device, the function returns with 'Key derivation not supported!' message.
The thing is that, in the datasheet (revision 2.6), it clearly says OptigaX supports key derivation in the first page.

Crypto ToolBox with ECC NIST P256, P384, SHA-256 (sign, verify, key generation, ECDH, key derivation)

I appreciate if anybody has any suggestion with that, if this is the case or not, and how to use key derivation with optigaX.

Best regards,
Vedat Show Less

i am using optiga trsut B sle95250 fro electronic authentication. i have to write into the non volatile memory of the device
according to the data sheet after successful writing of data . the NVM_ACT bit should be reset. but it doest get reset in my case. that means the NVM is still is progress.
can someone assist me in writing the data to NVM. Show Less

Hi

I have tested several javacards (Feitian D11CR, Infineon JTOP, G&D Smart Cafe) over T=0 and here is what I have observed.

If applet returns some data in case 4 APDU, the JCRE signals with SW 0x61XX that there is data available which terminal should retrieve using GET RESPONSE APDU.

However, if applet returns some data in case 2 APDU and Le does not match number of bytes to be returned, JCRE signals with error SW 0x6CXX, instructing that the same C-APDU has to be resent with correct Le.

For legacy reasons there are terminals who know how to handle 0x61XX, but fail to handle 0x6CXX response. Is there a way how to force JCRE to handle case 2 APDUs using 0x61XX (GET RESPONSE) omegle voojio method?

Show Less