TFC2022 – Systematic Innovation partnerships with AI and IT
27-29 September 2022, Warsaw, Poland and online

In the following example, the practical application of the trimming rules to a software process is demonstrated. The process describes the secure transfer of a user name/password combination to a smart card. In the smart card, they are stored for a later comparison to activate card services. The example presented here has been shortened and simplified for reasons of clarity.

The „secure transmission“ of the data to the smart card means that an attacker must not be able to read or change the transmitted data without being noticed. In the world of smart cards, the data is therefore encrypted (protection against eavesdropping) and provided with a cryptographic checksum (protection against unnoticed changes). This also happens in this example.

It should also be noted that the data transfer to the smart card is still usually done using an APDU protocol (https://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit). It is also common to encode the data in so-called TLVs to save storage space (https://en.wikipedia.org/wiki/Type%E2%80%93length%E2%80%93value).

The process shown below represents the protection of data transfer to smart cards that is commonly used today. In this example, the aim is to make the data structures used simpler and more efficient. For this purpose, the step-by-step construction of the data structures is considered as a process. The trimming rules for processes are then applied to this process in order to find approaches and ideas for new solutions.

Application of Trimming Rules

Step 1, productive function: Software assembles data for sending to the smart card.

• Applied trimming rule: The object of the analyzed function is eliminated from the system.
  • The object of the analyzed function is the data to be sent.
  • Idea: No more user name/password data is sent to the smart card for storage. Instead, the smart card creates a user name/password combination which can be used.

Step 2.1, supporting function: Add length to each user name and password.

• Applied trimming rule (A): The operation requiring the supporting function is trimmed.
  • The operation which requires the supporting function is the operation which extracts the user name/password on the smart card.
  • Idea: Instead of using user name/password, the data of the APDU or parts of it is used as a credential. Since this token consists of user name and password, the same method can also be used when comparing user name/password which this stored credential.
• Applied trimming rule (B): The supported operation is changed so that it does not require any support now.
  • Thus, the data extraction does not need a length any more.
  • Idea: User name and passwort have a fixed length, maybe padded with “empty characters”. This also would create great advantages in regard to padding for cryptographic checksum and encryption which has a fixed size or can be omitted.
• Applied trimming rule (C): The supported function performs the supporting function itself.
  • This means the data extraction method finds out the length by itself.
  • Idea: User name and password length are coded by inserting a special “stop character” at the end instead of a length information.
• Applied trimming rule (D): The analyzed supporting function is transferred to the preceding or subsequent operation.
  • Idea for preceding operation: The length is already part of the user name and/or password.
  • Idea for subsequent operation: The length is encoded as a part of the “tag” byte.

Step 2.2, supporting function: Add type (tag) field to each user name and password.

• Applied trimming rule (B): The supported operation is changed so that it does not require any support now.
  • So, the extraction of user name and password do not need the tag of the TLV any more.
  • Idea: Instead of using a tag, the order of user name and password is fixed: user name first, password after.
• Applied trimming rule (C): The supported function performs the supporting function itself.
  • Thus, there is no need to mark the user name/password combination in the data.
  • Idea: The extraction function recognizes user name and password by itself. The user name has to be an e-mail address and therefore to contain an @ while this character is forbidden in the password.

Step 3.1, supporting function: Add length field to user name and password combination.

• → See 2.1

Step 3.2, supporting function: Add type (tag) to user name and password combination.

• → See 2.2

Step 4, supporting function: Set the APDU field CLA, INS, P1, P2, and Lc

• Applied trimming rule (A): The operation requiring the supporting function is trimmed.
  • The supported function is the data transfer to the card. If there is no data transfer to the card, these fields do not have to be set.
  • Idea: Instead of initially storing user name and password on the card, the card generated user name and password by itself. Therefore, it is not necessary to send this data to the card.
• Applied trimming rule (B): The supported operation is changed so that it does not require any support now.
  • The data transfer to the card does not need the above APDU fields any more.
  • Idea: Use another hardware protocol.

Step 5, supporting function: Calculate the length of the padding necessary and add this padding.

• Applied trimming rule (A): The operation requiring the supporting function is trimmed.
  • The supported function is the calculation of the cryptographic checksum (CCS). Thus, no cryptographic checksum is calculated. But the message integrity has to be ensured.
  • Idea: Since the message is encrypted, the integrity of the message could be ensured by adding a non-crpytographic checkum which is also encrypted.
• Applied trimming rule (B): The supported operation is changed so that it does not require any support now.
  • This means, the CCS calculation does not need a padding anymore.
  • Idea: Use constant length for user name and password so there is no padding necessary and more.
  • Idea: Use a CCS which works on single bytes instead of blocks and therefore does not need a padding.

Step 6, supporting function: Calculate the cryptographic checksum and add it to the APDU.

• Applied trimming rule (C): The supported function performs the supporting function itself.
  • The supported function is the message integrity check after receiving the APDU in the smart card.
  • Idea: The integrity of the message is checked by checking the integrity of user name and password. This can be done by defining a set of valid characters for user name and password. If the integrity of the message is attacked, the encryption causes many bytes to be modified in an arbitrary way which can be detected easily.

Step 7, supporting function: Add type and length of the CCS.

• Applied trimming rule (C): The supported function performs the supporting function itself.
  • The supported function is reading the CCS from the APDU.
  • Idea: There is no more type and length for the CCS. Instead of searching the CCS using tag and length, the last <n> bytes are interpreted as CCS.

Step 8, supporting function: Calculate the length of the necessary padding and add the padding to the message.

• Applied trimming rule (A): The operation requiring the supporting function is trimmed.
  • The supported function is the encryption of the data.
  • Idea: The message is not encrypted any more. Instead, user name and password are hashed before sending to the card.
• Applied trimming rule (B): The supported operation is changed so that it does not require any support now.
  • The encryption of the message does not need the padding any more.
  • Idea: A stream cipher which does not need padding is used insteam of a block cipher.

Step 9, supporting function: Encrypting the data.

• Applied trimming rule (A): The operation requiring the supporting function is trimmed.
  • This means, the message is not decrypted any more.
  • Idea: Instead of user name / password, one time tokens are used to unlock services of the smart card. Therefore, no more encryption is necessary.

Step 10, supporting function: Add tag und length for the encrypted data.

• Applied trimming rule (B): The supported operation is changed so that it does not require any support now.
  • The supported operation is the decoding of the encrypted message.
  • Idea: Instead of using an extra tag and length byte, Lc and P1/P2 can be used to encode data meaning (tag) and data length.

This illustration is only a small part of the process of transferring a user name/password combination to a smart card. A precise analysis is important, even if there are many steps. Each step has the chance to trigger a new idea which goes far beyond the step itself.

Noteworthy is the „avalanche effect“ that occurs when the user name and password are of constant length. Many other length calculations and length information can be omitted then, which simplifies subsequent steps and even save (some) storage space/transmission capacity overall.

An implicit coding of information in algorithms is also possible: the arrangement of the data elements in a specific order also makes it possible to omit most of the „tags“, e.g. the type of the respective data element.