Search

Steganography In Tokenization

July 28, 2020


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





No Comments




Add Comment

 
 

We use cookies (including third party cookies) to ensure you get the best experience while visiting our website. Click "Accept Cookies" to accept the cookie usage. Click "Cookie Settings" to adjust cookie settings.

Mandatory Cookies

These cookies cannot be disabled

These cookies are necessary for the website to function and cannot be switched off.

Cookies:
  • .ASPXANONYMOUS
  • .DOTNETNUKE
  • __RequestVerificationToken
  • authentication
  • dnn_IsMobile
  • language
  • LastPageId
  • NADevGDPRCookieConsent_portal_0
  • userBrowsingCookie

Analytics Cookies

These cookies allow us to monitor traffic to our website so we can improve the performance and content of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited or how you navigated around our website.

Cookies:
  • _ga
  • _gat
  • _gid

Functional Cookies

These cookies enable the website to provide enhanced functionality and content. They may be set by the website or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.

Cookies:
  • __atuvc
  • euconsent

Targeting Cookies

These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.

Cookies:

Not used.