Topics In Demand
Notification
New

No notification found.

Blog
Steganography in Tokenization

December 14, 2020

IOT

206

0

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.

Functional-diagram-of-a-steganography-system-which-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.

Typical-architecture-diagram-for-a-Tokenization-Server

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.

Modified Architecture with Steganography

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.)


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


HughesSystique

© Copyright nasscom. All Rights Reserved.