Read Blog Post

Read Blog Post

Contributed on December 14, 2020

4

445

Steganography in Tokenization

Blog: NASSCOM Official Blog

Introduction:

Steganography is the art of hiding a secret inside information. The literal meaning is “covered writing”. Images are one of the popular sources of hiding secret information. Presented below is a basic functional diagram of a steganography system that works on images.

The process involves the following parts:

1. Secret Message: The secret which needs to be hidden in the image
2. Cover Image: The image in which the secret needs to be hidden
3. Key: The key from which the secret is encrypted. This is optional
4. Embedding function: The algorithm which embeds the secret into the image
5. Extracting function: The reverse algorithm which extracts the secret from the image

The secret is hidden inside the image such that there is no visible change in the image including its size. Following are some of the key areas in which steganography is currently used:

1. Digital watermarking: Provides an organization with a way to ensure the integrity of data they wish to disseminate by embedding copyright or other information in a digital file
2. Piracy Mitigation: Steganography is capable of mitigating piracy by aiding copyright marking. In the future, digital camera manufacturers could implement steganographic features as a part of camera firmware to annotate pictures with the photographer’s copyright information.
3. Defense/Spying: Transmitting secret data hidden inside images

Tokenization Use Case:

Tokenization is a method in which the sensitive data is converted into tokenized data. Many banking applications use this method to protect the user’s credit card information. A typical flow is:

1. Application Server passes the user sensitive information to the token server (e.g. credit card number)
2. Tokenization server converts this credit card to a token preserving the format. The mapping of the original data and the token is stored as an encrypted entry in the token database.
3. The token is returned to the application server which stores it in its own database
4. Only the authorized application is allowed access to the original data through the Tokenization server.

The tokenization server needs to give back the original data to authorized applications. For this, it either needs to maintain the tokenized to original data mapping or at least tokenized data to key (the key from which the original data was tokenized) mapping. This imposes security issues on the tokenization server itself for the stored data. Currently, most of the applications store this as encrypted data to protect it.

Steganography can come to help here and can make the tokenization server free from storing any such data. In most cases, the data which needs to be tokenized belongs to a user and hence it also has a user image (for e.g. the photo of a user who owns the bank’s credit card). In such cases, this mapping itself can be stored in the user’s image itself freeing up the tokenization server from storing any data.

Presented below is a typical architecture for a Tokenization Server. Note that the tokenization server maintains the encrypted database to store the mapping of tokenized data to original data.

The typical message flow is:

1. The Registered Application sends the credit card number to Tokenization Server for tokenization
2. The Tokenization Server tokenizes the data using the “key” from the Key Management Server.
3. The mapping of the tokenized data vs the key is stored in the encrypted database
4. The tokenized data is returned to the application
5. To retrieve back the original credit card number the Registered Application sends the tokenized data to the Tokenization Server.
6. The Tokenization Server looks up the mapping in its encrypted database and with the found key it gets back the original data
7. The original credit card number is sent back to the application

Presented below is the modified architecture with steganography. Note that the tokenization server does not maintain any encrypted database at its end and uses a steganography server.

The typical message flow is:

1. The Registered Application sends the credit card number and the user’s photo to Tokenization Server for tokenization
2. The Tokenization Server tokenizes the data using the “key” from the Key Management Server.
3. The key is hidden in the user’s photo using the steganography server. To further protect it the actual key is not hidden instead a reference of the key which is understood by the Key Management Server is hidden.
4. The tokenized data along with the user’s photo is returned to the application
5. To retrieve back the original credit card number the Registered Application sends the tokenized data and the user’s photo to the Tokenization Server.
6. The Tokenization Server gets back the key from the user’s photo using the Steganography Server and with the found key it gets back the original data
7. The original credit card number is sent back to the application

(This blog was originally published here.)

The post Steganography in Tokenization appeared first on NASSCOM Community |The Official Community of Indian IT Industry.