shopify / grizzly_ber

GrizzlyBer, the fiercest TLV-BER parser!

Grizzly BER

This library implements a TLV-BER parser, used for processing EMV transaction-related data.

This works differently from OpenSSL::ASN1 in that it does not decode tags (EMV-style). This is important when processing a long tag like 9F02 (Amount Authorized in EMV). OpenSSL will write it as the TLV-DER tag 82. GrizzlyBer maintains the original TLV-BER tag 9F02.

tlv_string = "9F0206000000000612"
 => "9F0206000000000612" 

OpenSSL::ASN1.decode([tlv_string].pack("H*")).to_der.unpack("H*").first.upcase
 => "8206000000000612" 

GrizzlyBer.new(tlv_string).to_ber
 => "9F0206000000000612" 

Installation

Add this line to your application's Gemfile:

gem 'grizzly_ber'

And then execute:

$ bundle

Or install it yourself as:

$ gem install grizzly_ber

Usage

Instantiate a TLV instance with a TLV-BER-encoded hex string to decode it

tlv = GrizzlyBer.new("DFAE22015A")

Access a value by tag

tlv = GrizzlyBer.new
tlv["DFAE22"] #returns [0x5A]

Set a value by tag

tlv = GrizzlyBer.new
tlv.tag = 0xDFAE22
tlv["DFAE22"] = [0xAA]
tlv.set_hex_value_for_tag("DFAE22", "AA")

Create multi-dimensional structures

tlv = GrizzlyBer.new
tlv["E1"] = GrizzlyBer.new
tlv["E1"]["5A"] = [0xaa, 0x12, 0x34]
tlv["E1"].set_hex_value_for_tag("57", "55A55A")

Encode the TLV instance back out to a hex string

tlv = GrizzlyBer.new("DFAE22015A")
hex_string = tlv.to_ber

Access EMV-specific values by name

tlv = GrizzlyBer.new
tlv["8A"] = [0x30, 0x30]
tlv["Authorisation Response Code"] = [0x30, 0x30]

Pretty-print EMV-specific data

puts GrizzlyBer.new "500B5649534120435245444954"
#50: Application Label
# Description: Mnemonic associated with the AID according to ISO/IEC 7816-5
# Value: 5649534120435245444954, "VISA CREDIT"

Contributing

1. Fork it
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Added some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request

grizzly_ber's Issues

Tags beginning with FF do not appear to be correctly processed

Steps to Reproduce

GrizzlyBer.new("FF0E0101").first.tag

Expected

FF0E

Actual

0E

Notes

We currently make use of several tags which begin with FF (including FF0D, FF0E and FF0F) in our EMV implementation. Based on my current understanding of the BER-TLV standard (as described in Annex B of EMV 4.3 Book 3), FF is permissible as the first byte of a tag:

Based on this table, a tag which has a first byte of FF (11111111) indicates a private, constructed tag which continues in the subsequent bytes.

The source of the issue appears to be here:

https://github.com/Shopify/grizzly_ber/blob/master/lib/grizzly_ber.rb#L63

The byte array representing the TLV is shifted until the first element is neither 0x00 nor 0xFF. However, based on the BER-TLV standard (as per the table above), 0xFF would appear to be valid values for the first byte of a tag.

There are several notes on the same page as follows:

Before, between, or after TLV-coded data objects, '00' bytes without any meaning may occur (for example, due to erased or modified TLV-coded data objects).
Note: It is strongly recommended that issuers do not use tags beginning with ‘FF’ for proprietary purposes, as existing terminals may not recognise ‘FF’ as the beginning of a constructed private class tag.

As a result, I can understand the removal of any 0x00 values before processing the tag. However, I do feel that perhaps this is not appropriate for the 0xFF value. What are your thoughts on this?