MintChip Messages

As mentioned earlier, there are two structured messages within the MintChip scheme:

  • Value Message
  • Request Message

Disassembling a MintChip message reveals multiple attributes within it.

MintChip Messages Un-Wrapped

The attributes(primitive data elements) within a Value Message are:

Name Description Length (octets)
Message Version The current and only version number is 1. Should the message structure change in the future this value will be incremented. 1
Annotation An optional user-defined text to attach to the message packet. It can be null. <256
SCAPP Version

The MintChip Smartcard Application(SCAPP) Version, indicates the version of MintChip software you have running on your chip. The higher nibble indicates the major version number and the lower nibble indicates the minor version number.

The current value for the SCAPP Version is 2.6 (hex 0x26)

1
Payer(Sender) ID See MintChip ID 8
Payee(Receiver) ID See MintChip ID 8
Currency Code This single octet indicates a currency. The value of 1 indicates Canadian Dollar which is the only currency in usage at the moment. 1
Transfer Value The amount specified in cents. This value is a three octet unsigned integer value with a range of (0 - 16777215). 3
Random Challenge The Random Challenge serves two functions:
  1. To prevent the creation of duplicate messages by increasing the uniqueness of a Value Message.
  2. To link both Request and Value messages together as a transaction pair.
4
Datetime

The DateTime field encodes the date and time the Value Message was generated. The contents of this field are supplied by the MintChip device itself. The secure element neither checks nor verifies the contents. The date and time is provided for the convenience of the participants and plays no part in the security of the Mintchip System.

3 Octets coded as follows with the most significant bit (MSB) first.

  • Bits 23-20 : Year offset from Base Year (0-15)

    Note: The base year is defined as 2010, as per the current release R2 of this specification. Mintchip interface devices are made aware of the base year for each release in provided public Mintchip interface specifications.

  • Bits 19-16 : Month (1-12)
  • Bits 15-11 : Day (1-31)
  • Bits 10-6 : Hour (0-23)
  • Bits 5-0 : Minutes (0-59)
3
TAC The Transaction Authentication Code(TAC), is generated by a MintChip and used by the Royal Mint as a additional check of authenticity. 24
Signature The role of the signature is to ensure that the SCAPP version, Payer ID, Payee ID, Currency Code, Transfer Value, Random Challenge, DateTime and TAC have not be doctored in transmission. The construction of the signature is explained here. 128
Payer(Sender) Certificate The certificate used to sign the value message. This is used by the Receiver to check that the value message has not been tampered with. <1024

The attributes(primitive data elements) within a Request Message are:

Name Description Length (octets)
Message Version The current and only version number is 1. Should the message structure change in the future this value will be incremented. 1
Annotation An optional user-defined text to attach to the message packet. It can be null. <256
Payee(Receiver) ID See MintChip ID 8
Currency Code This single octet indicates a currency. The value of 1 indicates Canadian Dollar which is the only currency in usage at the moment. 1
Transfer Value The amount specified in cents. This value is a three octet unsigned integer value with a range of (0 - 16777215). 3
Include Cert This boolean value lets the payer know whether to include his certificate within the Value Message. This value should always be True (0xFF)hex. 1
Response URL The Response URL, tells the Sender where to send the value message. <256
Random Challenge The Random Challenge serves two functions:
  1. To prevent the creation of duplicate messages by increasing the uniqueness of a Value Message.
  2. To link both Request and Value messages together as a transaction pair.
4

Message Assembly

The same process is used to package both Request & Value MintChip messages.

The diagram on the right displays the steps involved in the creation of a MintChip Request message.

  1. Firstly establish the values for the primitive data elements. See above.

  2. A formal structure is applied to the data elements using ASN.1 Distinguished Encoding Rules (DER). ASN.1 comprises of primitive data objects (boolean, integer, Octet string, etc) that can be constructed to define more complex data structures, the constructed types (Sequences, and Sets).

    Within the diagram, the data elements; Version, PayeeID, Currency etc are primitive types contained with the constructed types Value Message Request & Message Packet etc.

    Each element (primitive & constructed) is given a tag indicating the type of data and a length. The formatting is referred to as TLV - Tag-Length-Value.

    For the full MintChip message ASN.1 specification, see here.

  3. The ASN.1 DER message is Base-64 encoded.

    The transmission method is left to the user to decide its details. However to help identification of MintChip messages, the MintChip scheme uses the MIME-types:

    • application/vnd.scg.ecn-request and file extension *.erq for a Request Message.
    • application/vnd.scg.ecn-message and file extension *.ecn for a Value Message.

Message disassembly

Unpacking consists of the same three steps as in reverse.

The diagram on the left displays the process of unpacking a MintChip Value message (Sometimes referred to as a Value Message Response).

  1. The base64 message is decoded into binary (Structured by ASN.1 DER rules).

  2. Extract the value of each primitive data element.

  3. Since many of the data elements are encoded as Octet Strings, to record or display these values you will need to convert them into your chosen programming languages data types.