LAU for SWIFT Message Partners 1


Introduction

In past couple of years SWIFT started taking security more serious than before, SIP (Shared infrastructure Programme which regulates Service Bureaux activities) is becoming more security-oriented as of it’s version 2 and the recent 3, CSP (Customer Security Programme which is intended to become a framework for customers to be compliant with certain security controls) has became mandatory and SWIFT products are getting enhanced with more security features.

LAU (that stands for “Local Authentication” and mainly refers to HMAC-SHA256 digest which signs important parts of the message and then adheres to it) was always there in Alliance Access product of SWIFT but (as per my experience with many customers) was not been used as it must. Nowadays enforcing SIPv3 and CSP is leading SWIFT users to deploy LAU in Message Partners.

First of all let’s review definitions of the AI, MP and LAU:

AI: The Application Interface

Alliance Access uses its application interface to link to other applications, back-office systems, printers, and customer‘s internal networks. (“Alliance Access 7.2 Service Description” Document / section of “Integration with Customer Business Applications” – here)

The Application Interface controls the transfer of messages and files between Alliance Access Configuration and back-office applications, printers, or any other system that communicates with Alliance Access Configuration. Suitable messages for transferring include SWIFT FIN, MX, FileAct, and system messages. Suitable files include payload files, or files that contain several messages (such as for Bulk Payments). Within the Application Interface, a message partner represents the external application or product that communicates with Alliance Access Configuration. A message partner profile specifies how each message partner communicates with Alliance Access Configuration, and allows you to control and monitor the communication sessions. (“Alliance Access 7.2 Configuration Guide” Document / Section of “Application Interface” – here)

MP: The Message Partner

A message partner is an external application, such as, a back-office application, a printer, or a mainframe connection. The Application Interface manages the transfer of files and messages between Alliance Access and a message partner using the profile that is defined for that message partner. (“Alliance Access 7.2 Configuration Guide” Document / Section of “Message Partner” – here)

LAU: Local Authentication

According to SWIFT document ” Developers Toolkit For Alliance Access 7.2 ” which includes the important topic of “Local Authentication (LAU) Principles and Implementation” (This Link) Local Authentication (LAU) allows users to authenticate the origin of the message and guarantees its integrity by using Hash-Based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-256) signatures. The signature algorithm (HMAC-SHA-256) in combination with a symmetric key is used to compute the signature of a message. The symmetric key is shared by both the back-office application and Alliance Access.

Now that you know the exact definitions, let’s go to LAU concept.

In our example I used RJE message and C# language. In case I find enough time I will publish more examples with other formats (like XML) and JAVA.

EXAMPLE MESSAGE (RAW, NO CHECKSUM):

{1:F01BANKAEBBAXXX0004000001}{2:I999BANKAEBBXXXXN}{4:
:20:LAUTEST1
:79:THIS IS EXAMPLE1 FOR LAU TEST RJE CSHARP
-}

EXAMPLE LAU KEYS:

LAU Key Left: LEFTLAUCSHARPNET

LAU Key Right: RIGHTLAUSWIFTRJE

MESSAGE DIGEST (HMAC-SHA256):

27043195182EB981224C1FFC843D5DB00879E3C05D36AF0F36BBE2207E0E5C62

SIGNED MESSAGE:

{1:F01BANKAEBBAXXX0004000001}{2:I999BANKAEBBXXXXN}{4:
:20:LAUTEST1
:79:THIS IS EXAMPLE1 FOR LAU TEST RJE CSHARP
-}{S:{SPD:}{MDG:27043195182EB981224C1FFC843D5DB00879E3C05D36AF0F36BBE2207E0E5C62}}

 

What to do in C#?

Thank to the “System.Security.Cryptography” class of .Net, Calculating HMAC-SHA256 digest in C# is so simple. The procedure of calculating digest is a easy as below 3 easy steps. The process in JAVA is similar. (Update of April 8th 2018: JAVA CODE IS ADDED!)

1- Concatenate Left LAU part (16 chars) and Right LAU part (16 chars) to result a 32 characters long key, then convert it to an array of bytes (Let’s name it “THEKEY”)

2- Convert the subject (here in our RJE example is the message from the beginning of block 1 to the end of block 4) to an array of bytes (Let’s name it “TEXT”)

3- use the “System.Security.Cryptography.hash.ComputeHash()” method to calculate the digest (Hash Value) in array of bytes, then convert it to String in Uppercase

C# Code for calculation LAU Digest

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

JAVA Code for calculation LAU Digest

JAVA Code for calculation LAU Digest

What next?

Your message partner application (we usually refer to it as BOA or Back-Office Application) must be able to perform below actions:

1- When generating messages, calculating the HMAC-SHA256 digest using the pre-shared LAU keys and add it to the end of the message before passing it to Alliance Access.

2- When receiving a message from Alliance Access, calculating the HMAC-SHA256 digest using the pre-shared LAU keys and comparing it with what has been amended to the message by Alliance Access.

Security Matters!

It’s important to understand why we are using LAU mechanism in SWIFT messaging interfaces. The goal is to assure our Message partner (BOA) has a pre-shared secret key with it’s Alliance Access, so they can authenticate messages of each other. That makes you certain no one in the middle can tamper the transferred messages. The true practice is to embed such codes in your BOA to do it instantly before emitting the message or after receiving them.

It’s good to use different LAUs per Message Partner and avoid dummy values like sequenced numbers.

Sounds funny but I have heard about a non-professional design where some LAU-calculator application resides between Alliance Access and BOA, BOA puts messages in a folder and the application adds digest then Alliance Access takes the signed message. I still can’t understand how someone dares to propose such mistake and how someone may accept to deploy it; Just assume a scenario when some body puts an unwanted message in that folder, or modifies a message of your BOA in that folder!

Final Words!

My intention is to show you how much easier it is than what it sounds. Enjoy it and write your questions here in the comments.

 

Sincerely Yours,

Mohammad Diba

 

 


About Mohammad Diba

Mohammad Diba is a SWIFT expert with more than 12 years solid experience in SWIFT messaging interfaces and services. He has Technical, Consultancy and Management skills. Mohammad is currently head of a Service Bureau team.


Leave a comment

Your email address will not be published.

One thought on “LAU for SWIFT Message Partners

  • Martin Ullmann
    Martin Ullmann

    Great article Mohamad! I would add small note. Swift’s CSP program mandates to use 2-way TLS authentication or 1-way TLS authentication with LAU key.
    Would be interesting to see your code for XMLv2 format 😉