Layer7 API Management

 View Only

Converting data hashed using the Generate Security Hash assertion 

Jun 03, 2015 09:35 AM

Background

The Generate Security Hash assertion is used to generate cryptographic hashes of provided data in order to provide rudimentary data integrity checking. The assertion can provide hash-based message authentication codes to hash data with a secret cryptographic key. It can also provide unauthenticated hashing with simple cryptographic hash algorithms such as MD5, SHA-1, or SHA-256. The Gateway will provide these hashes as a context variable to be utilized or leveraged in a published service policy. In some circumstances, a hash function performed by the Gateway may not match a hash function performed by an external tool

Presentation

A service policy might be invoked that runs a SHA-1 hash function against a string: helloworld. This would be executed using the Generate Security Hash assertion as follows:
hashProb.png

This would result in the following hash sum being presented:

hashAudit1.png
This hash sum may not match the hash sum provided by certain tools such as online hash generators, Linux-based hash generators (such as sha1sum or md5sum), or applications or functions within other programming languages. For example, the hashed value displayed above is a hash some that has been Base64-encoded from the raw binary data. Most tools and functions present hashed data encoded in Base16. For example, a comparison of the SHA-1 sum generated by the Policy Manager and a SHA-1 sum generated using the sha1sum tool from Unix is:
Gateway: at+xg6SiyUovktq1redipHiJpaE=
sha1sum: 6adfb183a4a2c94a2f92dab5ade762a47889a5a1

There is a marked difference between the two. It is immediately clear that the top result is Base64-encoded whereas the bottom result is Base16-encoded. This gap must be addressed in order to accommodate for certain external applications and endpoints that may present SHA-1 hashes in Base16.

Resolution

A Gateway service policy can be authored to decode and re-encode hashed data into an appropriate format. A hash operation is performed upon binary data and then encoded in a certain way for consumption. The Gateway encodes the raw hashed binary data in Base64 whereas other applications might encode it in Base16. The following service policy displayed below will hash a string, decode it, and re-encode it in Base16:

hashPolicy.png
This service will generate a particular security hash, decode it into raw binary data and then re-encode it in base16. Auditing a string of "helloworld" would show the following results for each hashing operation:

hashAudit2.png

In the example above, the base64-encoded hash is printed first and the base16-encoded hash is printed second.

A service policy that is capable of this transformation is attached to this article.

Statistics
0 Favorited
13 Views
1 Files
0 Shares
3 Downloads
Attachment(s)
zip file
reencodeHashedData.xml.zip   655 B   1 version
Uploaded - May 29, 2019

Tags and Keywords

Comments

Jun 16, 2017 10:30 AM

Hi Sathis, Whats your requirement .  I am not able to see . 

Jun 04, 2015 09:55 AM

If you need immediate assistance then I would recommend opening a new issue with CA Support via CA API Management Support (formerly Layer 7). You can also open a request via email at API-support@ca.com

Jun 04, 2015 04:22 AM

Hi Eric,

 

Have you got time to, went through my scenario? Could you replicate there? .

Please feel free to ask me any details.

Our whole security implementation is struck there.

Jun 03, 2015 10:49 AM

Its not the the tools are wrong. The tools are just presenting binary data in a different wash. Hashes are binary data that cannot be represented in normal character sets. You need to encode it in some way to make it human readable. That is where the base16 and base64 come in. The Gateway encodes binary data from this assertion in base64. Common applications and tools encode binary data in base16. This article remediates the differences.

Related Entries and Links

No Related Resource entered.