But I was struck by how the architectural flaw leapt out and screamed HIT ME HERE! 1/
They might be authorised, but it’s like they slapped a sticker on to say that.
Not good enough. 3/17
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
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
(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
The inbound is its authorisation to process, the outbound is an authorisation to the next node.
Sends, to the next node. 10/17
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
For top points, integrate back into the customer. 13b/17
Well, actually no, it’s an end to end security model. That should be the beginning and end of the discussion. 14/17
“I know that what you see is what I see.”
15/17
(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
(But don’t get your hopes up. There are multiple reasons why it’s not coming to SWIFT any time soon.)
17/17
Russian Dolls - a design pattern for end to end secure transactions
financialcryptography.com/mt/archives/00…