Financial Cryptography: Russian Dolls - a design pattern for end to end secure transactions

February 09, 2020

Russian Dolls - a design pattern for end to end secure transactions

This is a great research attack on a SWIFT-using payment institution (likely a British bank allowing the research to be conducted) from Oliver Simonnet.

But I was struck by how the architectural flaw leapt out and screamed HIT ME HERE! 1/17

@mikko We were able to demonstrate a proof-of-concept for a fraudulent SWIFT payment message to move money. This was done by manually forging a raw SWIFT MT103 message. Research by our Oliver Simonnet: labs.f-secure.com/blog/forging-swift-mt-payment-messages

Here’s the flaw: SAC is a flag that says signature verification and RMA (Relationship Management Application) authorisation and verification was successful.

Let me say that more clearly: SAC says verification is done. 2/17

The flaw is this: the SAC isn’t the authorisation - it’s a flag saying there was an auth. Which means, in short SWIFT messages do not carry any role-based authorisations.

They might be authorised, but it’s like they slapped a sticker on to say that.

Not good enough. 3/17

It’s hard to share just how weird this is. Back in the mid nineties when people were doing this seriously on the net, we invented many patterns to make digital payments secure, but here we are in the ‘20s - and SWIFT and their banks haven’t got the memo. 4/17

They’ve done something: LUAs,MACs,CHKs.

But these are not authorisations over messages, they’re handshakes that carry the unchanged message to the right party. These are network-security mechanisms, not application-level authorisations - they don’t cover rogue injection. 5/17

Let’s talk about a solution. This is the pattern that Gary and I first explored in Ricardo in mid-nineties, and Chris Odom put more flesh on the design and named it:

Russian Dolls

It works like this: 6/17

Every node is an agent. And has a signing key.

The signing key says this message is authorised - not access controlled, not authentically from me but authorised by me and I take the consequences if it goes wrong. 7/17

Every node signs their messages going out at the application level.

(as an aside - to see this working properly, strip out LUAs and encryption, they’re just a distraction. This will work over the open net, over raw channels.) 8/17

Every node receives inbound messages, checks they are authorised, and only proceeds to then process authorised messages. At that point it takes over responsibility - this node is now responsible for the outcomes, but only its processing, bc it has an authorised instruction. 9/17

The present node now wraps the inbound message into its outbound message, and signs the whole message, including the received inbound.

The inbound is its authorisation to process, the outbound is an authorisation to the next node.

Sends, to the next node. 10/17

Repeat. Hence the message grows each time. Like Russian Dolls, it recursively includes each prior step. So, to verify:

take the message you received, check it is authorised.

THEN, pull out its inner message, and verify that.

Repeat all the way to the smallest message. 11/17

This solves the SWIFT design weakness: firstly there is no message injection possible - at the message layer.

You could do this over the open net and it would still be secure (where, secure means nobody can inject messages and cause a bad transaction to happen). 12/17

2- as the signing key is now responsible as a proxy for the role/owner of that node, the security model is much clearer - PROTECT THAT KEY!

3- compromise of any random key isn’t enough bc the attacker can’t forge the inbound.

For top points, integrate back into the customer. 13b/17

OK, if you’ve followed along & actually get the pattern, you’re likely saying “Why go to all that bother? Surely there is a better, more efficient way…”

Well, actually no, it’s an end to end security model. That should be the beginning and end of the discussion. 14/17

But there is more: The Russian Dolls pattern of role-based authorisation (note, this is not RBAC) is an essential step on the road to full triple entry:

"I know that what you see is what I see."

15/17

In triple entry, the final signed/authorised message, the Big Babushka, becomes the 'receipt'. You:

(a) reflect the Babushka back to the sender as the ACK, AND
(b) send it to SWIFT and on to the receiving bank.

Now, the receiving bank sees what client sender sees. 16/17

And you both know it. Muse on just what this does to the reconciliation and lost payments problem - it puts designs like this in sight of having reliable payments.

(But don’t get your hopes up. There are multiple reasons why it’s not coming to SWIFT any time soon.)