> 1. All parties MUST use a key length of 2048 bits for their RSA keys.
What is the point of this? Seems to me there'd be no problem in using 3072 bit RSA keys, which makes more sense given that the lowest security symmetrical encryption algorithm permitted for use is AES128, and the difficulty of breaking AES128 is roughly equivalent to breaking 3072 bit RSA.
I did, but it doesn't make sense in the context of the first one (it doesn't matter that peers may accept longer keys if everyone must use 2048 bit keys). But with your correction it makes sense.
I'm still interested in the reasoning behind accepting 2048 bit RSA keys instead of setting a 3072 bit minimum, which corresponds to AES128 in security[1][2].
Quite many seems to be using 2048 bits RSA-keys for SSL-
certicaties:
openssl s_client -connect www.google.com:443
Server public key is 2048 bit
openssl s_client -connect www.twitter.com:443
Server public key is 2048 bit
openssl s_client -connect www.hsbc.com:443
Server public key is 2048 bit
openssl s_client -connect www.citibank.com:443
Server public key is 2048 bit
I don't know the limitations in all the legacy bank systems around the world, but I know my personal OpenPGP smart-card is limited to 3072 bits, but that card is quite modern.
Maybe the limits for legacy systems is even worse.
The System Design supports multiple keys per bank, so if a stronger key length is required, keys can easily be upgraded in the future.
But, I agree the strongest key length possible should be used if possible, which is 4096 bits according to the OpenPGP specs.
We will update the specs accordingly.
If any bank for some reason cannot support 4096 bits, then I think it's fair to require at least 2048 bits, as that key length is used by a lot of high profile websites, including banks, already today. (see above list)
What's the motivation for this? Is it coming from inside the industry/is it a suggestion/fun project?
I'm don't understand the purpose - it's all about transmission, not data. Banks could sure do sure do with a standardised API, but is interbank message encryption a problem needing solved? I've haven't heard anything like that.
The author is very sure of it's production-readiness. If this transpires to be true, then I could easily see this spec as a good way to encrypt message-based data of all kinds. But where does this bank angle come from?
Helpful. Are you using this in production with European banks?
I saw that on one of the interactive maps on your site there's no line to/from the UK, which is hardly surprising if you are - I would be staggered if they got on board with anything outside their little circle. Are banks in mainland Europe open to this kind of innovation?
Yes, it's in production by some banks and financial institutions in Europe. Most banks are still using SWIFT though.
I think the main reason why BankAPI has been accepted, is actually the lack of innovation. Banks are in general very skeptic to new "unproven" technology, but as BankAPI relies on old standards like TCP/IP, OpenPGP, RSA, SHA512 and HTTPS, there is nothing "unproven" in it to be afraid of.
In my few years in finance, i never came across anyone using SWIFT. It was all SFTP and the occasional HTTPS POST, with all the key distribution done manually.
But then, i didn't work in anything in the area of settlement or trade execution - it was in the general area of equities advice, so we moved research, trade ideas, restricted lists, prices, performance calculations, etc.
Given that SFTP and HTTPS are doing the job mostly adequately, i'm not sure why i'd adopt BankAPI (or rather, layer BankAPI on top of the HTTPS i already have). What value does it add?
BankAPI is actually using HTTPS, but doesn't depend on SSL alone, as the files/messages are also encrypted/signed using OpenPGP.
This means banks would not have to trust all the CAs who issue SSL-certificates, as the OpenPGP public keys are imported once for each bank you wish to communicate with, and won't change unless you explicitly update them.
The value it adds is the two layers of security (HTTPS+OpenPGP) and the "DeliveryReceipt" which makes it possible for both parties (the sending and the receiving bank) to prove they did send and did receive all files/messages sent over BankAPI.
I find that quite amazing. There are a few services around that talk to UK banks, and every single one screen-scrapes to get it done (yes, including MITMing your auth creds) because the banks here would never implement a public API.
I've heard of a proper API once - it was only available to corporate account holders with turnover of £3m+ and the bank had to QA your code.
And yet when I took them to task for validating user passwords with `/^[\d\w]{8,16}$/` they refused to see a problem.
> The decentralized design of BankAPI protocol ensures noone controls it, noone owns it, noone can shut it down, just like the Internet. The un-innovative design of BankAPI protocol ensures noone can critizise it, as there is nothing new invented, it's just a combination of existing well proven technologies.
I don't think I'm comfortable with the 1960s singer-songwriter Peter Noone having this much control of your system.
</snark>
This is a grammatical pet peeve of mine[1], principally because I used to use it exclusively and was horrified when a girl I liked at the time corrected me.
this type of encrypted messaging is super common between banks and third parties. it's usually done in a similar manner to what is implemented here but in SFTP and every bank has it quirks/a different system for ACKing transmissions. a standard would be nice :)
I dont know if anyone is interested, but someone once asked me to look into the SWIFT messaging system, i'd never done anything with banking before. I made a little once page app as i learned it which breaks it down to what everything does.
It doesnt do anything except send to a validation API, which currently is down cuz i've not touched it in months, but i figured some people might find this interesting.
I am interested. After looking up SWIFT I can't really get a grasp on what kind of things you can do with it if you're not a financial institution. Do you have any examples?
I'm afraid i didnt get that far, to my knowledge theres no use for it outside the banking system. The example above is of an MT999 which is to send generic messages to and from systems, other codes do other things, have a google, theres a bunch of info on it.
I don't think that's how banking works to be honest.
Money move from bank to bank via the countries central banks if I'm not mistaken. Then the central bank reconcile everything in batch processes to ensure that banks aren't just making up money (well more than they are legally allowed to).
Denmark has had a few occasions in the last few years where this has failed because one bank failed to deliver their transactions one night.
SWIFT is generally reserved for international transfers. In the United States domestic bank transfers use ACH which involves FTPing fixed-width-column EDI files to and from the Federal Reserve every night. ZenPayroll had a really good series on how it all works a few months ago:
... for more background, SWIFT is an essentially global monopoly on international interbank transfers with all messages recorded in full by the US and its allies[1]. Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EU<->EU state transactions. It opened its first 'international center of operations' in Virgina (~CIA HQ) as a first order of business after accruing partaking institutions at a speed frankly unbelievable given the technology of the time. It was billed as a telex replacement.[2] After recently dispatching with its carefully developed apolitical facade and banning Iran (after receiving Europe's blessings at the behest of UANI, which is essentially Mossad + CIA old guard[3]), it pissed off India (who depend on them for energy security) and raised eyebrows in Russia and China.
While it's probably critical for the future of humanity for a project like this to succeed, frankly anything that leaves the trust and reputation aspects to manual negotiation as per conventional business is just lipstick on a pig. In this sense, Bitcoin is superior. For some more ambitious ideas forming in this area check out http://ifex-project.org/
Before SWIFT moved to SwiftNet they used X.25, before that they used telex. Of course there was plenty of overlap during the transition, as far as I know X.25 for financial institutions is now all but dead, maybe there are still some ATMs connected to ISDN lines (X.25 packets can be sent via either one of the 'B' channels up to 64 kbps or via the 'D' channel at 16 kbps) but those are not part of SWIFT anyway but of a banks local IT infrastructure.
Thanks for a well written description and background of SWIFT, I think it is accurate.
I have a question on this paragraph:
>While it's probably critical for the future of humanity for a project like this to succeed, frankly anything that leaves the trust and reputation aspects to manual negotiation as per conventional business is just lipstick on a pig. In this sense, Bitcoin is superior. For some more ambitious ideas forming in this area check out http://ifex-project.org/
Does "for a project like this" refer to SWIFT or BankAPI? If SWIFT, then I understand. But if BankAPI, then you have misunderstood, because it does not "leaves the trust and reputation aspects to manual negotiation", since it's decentralized and peer-to-peer (or in this context bank-to-bank), just like a lot of other successful peer-to-peer technologies of which you mentioned one.
What I meant by "a project like this" was a concrete, functional alternative to existing status-quo systems, with SWIFT as the implied primary target for forced deprecation.
I think banking is an artificial industry, one that doesn't really have to exist. I believe that money that is state issued, electronically issued, trust that can be quantified, reputation and physical goods are all equally valid assets for forward-looking exchange protocols. I believe that any distinction between participants is farcical and that risk management models, encryption preferences, topology specification and other qualitative decisions regarding deployment must be left out of scope.
To clarify my original comment further, I do think that BankAPI, just at a glance, is probably focusing too much on the conventional world of banking rather than looking at the big picture ... which has nothing to do with banks and everything to do with a potential revolution in the way we organize society, removing anachronistic middle men and vested interests who consistently fail to demonstrate any meaningful reason for being while extracting vast quantities of wealth from society at large and encouraging the continuation of a socio-political and economic trajectory that will see our environment destroyed within a generation.
> Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EU<->EU state transactions.
The ability of the US to seize USD transaction has nothing to do with any control they might have over SWIFT. All USD transfers -- even USD transfers between two EU citizens -- hapen via a US bank, because only US banks can have a USD balance.
There are USD balances right across the world. Some of them are backed with cash (really!). That's fundamentally because, unlike bitcoin or company shares, currency is what's known as a 'non-consolidated' asset: ie. there is no central ledger anywhere in the world with a complete list of who owns every piece of currency on issue, like exists for Bitcoin on the blockchain.
The total balance of electronic currency in a commercial bank is tracked by the central bank of the currency in question (eg. the Federal Reserve for USD for the US, Danmarks Nationalbank for DKK in Denmark).
The Federal Reserve is the authority on the (electronic) USD balance of each US bank, and no non-US banks can have a USD balance (this happens via so-called intermediate banks where, for example, a Danish bank has a USD balance with a US "intermediate" bank).
Intrabank transfers (transfers from one account at a bank to another account in the same bank) is simply a change in that bank's local database. Interbank transfers (a transfer from one commercial bank to another) within the same country is handled by the central bank (since the central bank is the authority on the commercial bank balance of the currency they produce/manage).
The money transfer between customers' accounts consists of two steps: The communication of the transaction records (who to debit or credit and what to print on their statement) and the settlement of the resulting total money transfer between the banks. The latter is what usually happens through the central bank, where both banks have accounts that are used to settle the total of all money movements between the two banks within a given period, in a single transaction between the two accounts. The transmission of the transaction records is independent from that and can happen in any way the banks see fit, including SWIFT (and sometimes the central bank, if it offers that service).
Really, my experience is the opposite. FIX is old, like 1992 old and its starting to show its age. Not that age is necessarily a bad thing, I just wanted to point out its age as your comment makes it seem like an up and coming protocol. My experience is that more and more firms are leaving it.
Its' no longer suitable for market data. Its barley suitable for sending order messages around. And with the explosion of order types and growth I'm not sure that's a valid statement anymore.
Its not anywhere near as compressible as binary formats. Many exchanges and dark pools have already replaced it with binary formats.
What fix does have going for it are quickfix/j and a wealth of knowledge, which will keep it relevant for a long time, but
FIX can operate as a binary, compact ASCII or XML-like protocol. FIX has support for multicast. FIX has open source Java, .NET and C++ implementations. It's got a thriving development community and a non-profit, industry-driven standards body. FIX isn't going anywhere. No buts.
But FIX _is_ going away in US equities as all of the major exchanges have adopted native binary protocols. We still have to deal with it in other asset classes, but I (as a developer) am not really happy about it. FIX/FAST is a massive pain in the ass relative to simple binary protocols.
With banks considering the switch to the Cloud, how would this specification address the issue of key management on the Cloud? That's the "key" to Cloud security. Currently, there are solutions available which are obnoxious for those who <i>really</i> want security of their data and not just a <i>tick mark</i> on some data security checklist because key managers CANNOT be hosted on the Cloud. The dominant approach (CipherCloud for example) is to have an encryption gateway in-house which encrypts/decrypts/tokenizes on-the-fly before data leaves for the Cloud. Their approach is to enable support for popular SaaS apps like SalesForce and archive storage like S3 etc which makes sense BUT then again, it's dependent on whether the vendor would add support for more apps or open the API for 3rd party devs to plug in support for other Cloud apps.
A networked HSM is certainly one approach to solving this. Often, corporations -- not just banks or financial institutions -- will rent a cage in the same data center as the cloud provider, and will run a dedicated line from their cage to the provider. The networked HSM will store all key material, and whatever sensitive servers/databases/applications are provisioned in the cloud will leverage it for cryptographic operations.
In theory... 1) The keys never leave the physically-hardened HSM, so they're "safe", 2) Transmission between the HSM clients and the HSM is done over an encrypted channel, so that's "safe"
There's always a very high risk of implementing things improperly and negating any security benefits of this type of setup, but that risk exists with on-prem infrastructures, too.
They used to. Now Cisco is also building their "enterprise" Cloud to target their financial sector clients (banks et al) because they're seeing business going to Amazon and decline of dedicated data centers to do something which can be done more efficiently by Amazon et al. Security is just going to become even more important and significant
More and more traffic to and from banks goes over the public internet, it is a matter of time before 'dedicated lines' will be limited to the military and that's pretty much where the internet originated so at a guess even they are using the internet except for when it is extremely critical to get traffic from 'a' to 'b' with minimum latency.
> More expensive, too, but sometimes security should trump expense.
All security is a trade-off between 'enough security' and expense. There is no such thing as 'absolute security', if dedicated lines are not measurably more secure than the public internet then choosing to route your traffic via the net rather than via dedicated lines is the right decision.
Banks are in general not 'stupid' when it comes to what they do with their data, they try to do their best within the triangle of security, expenses and technical demands.
If you think using 'public communication methods' for the transport of core financial information is stupid then I guess you are also against banks that are connected to the internet using websites, against banks that use 'swiftnet' (SWIFT is a provider of a secure network used to transfer financial information between banks, which - surprise - has been compromised in the past by the NSA and where payments in transit between two other countries has been seized by the USA because those payments violated a US policy).
In the end, at some point a bank will have to trust the wires and the parties that maintain those wires. From a banks point of view an operator like SWIFT and the public internet vary in degree as to their security but which one to use will always be a business decision and as noted above even SWIFT is not 100% secure and might in some ways be less secure than the public internet.
I also wonder how you propose banks communicate with their customers and with their branch offices.
Here is a nice page on the connectivity options a SWIFT partner gives to its customers all the way from DSL to dedicated lines:
> How stupid do you have to be to trust core financial information to public communication methods?
The CIA got a lot of info out of the Soviet Union by tapping their military undersea communications cables, which carried unencrypted data as they assumed they were protected.
Sometimes the dangers of public communications methods lead to better security in that you have to consider it rather than assuming you're safe.
Dedicated lines are exactly as secure as the internet - i.e., not secure, so there's no difference on that regard. From a security viewpoint, they're treated as unsecure as a number of third parties (the network providers and such) may have access to it; so you have to encrypt all data in transit in the exact same manner as you would on an internet connection.
In finance, you get dedicated lines for bandwidth/latency guarantees (i.e., no congestion out of your control) or for redundancy and fault tolerance; not for security.
If you publish any kind of price, that affects your negotiation options if you want to do individual pricing/haggling for each customer.
Also, a multitude of factors affect the 'true' price including various risk estimates of your company, and it would be counterproductive to say "factor X, as measured by Y, gives you a price increase/decrease of Z", as that would just result in gaming the measurement and misleading about the nature of your business.
I think it's excusable for a relatively niche B2B service where there's likely a huge variation in the size of their customers. Price discrimination is hard.
Why this weird API? I dunno, I would expect exactly two functions, one for sending a "file", and one for receiving whatever is new in the inbound queue, with the abstraction taking care of delivering the enqueued files to their destination!? And maybe a callback API so I don't have to poll for new inbound "files". Also, I'd expect the abstraction to provide an ordered, lossless stream, rather than some weird "file sync" which seems to lack all reordering and replay protection?
Author here.
It's decentralized because the FromBank and the ToBank communicates directly over the Internet using TCP/IP+HTTPS+OpenPGP, which is different from a centralized communication system like SWIFT, where the FromBank would first send the message to ToBank's SWIFT address (so called "BIC"), and wait for ToBank to check their SWIFT "inbox".
Compare:
FromBank <-> ToBank (BankAPI, decentralized)
vs.
FromBank <-> SWIFT <-> ToBank (SWIFT, centralized)
(FromBank = Bank sending the message)
(ToBank = Bank receiving the message)
What happens when the beneficiary bank can't be contacted? Their servers may be down, they may be getting DDoSed, a production upgrade may have gone wrong and they're inadvertently dropping all messages.
That lumps a whole lot of complexity on FromBank, if the onus is on them to ensure ToBank correctly received the payload.
SWIFT takes care of all of this. You also have to guarantee to be connected to the SWIFT network for at least 7 hours per day to process your inbox, and new banks get silo'd in a test area for two months where they have to prove their systems are functioning properly within the SWIFT env before they're connected for real.
As long as FromBank gets its confirmation when it posts to SWIFT, job done. SWIFT takes care of ensuring it gets to ToBank.
We are already using SWIFT for much of our messages from/to banks, but it comes with a high cost and a lot more complexity than BankAPI, as messages are not sent directly from A to B, but from A to SWIFT, and then B must check their SWIFT "inbox" to receive the message from A.
With BankAPI, the response from the request comes directly from the beneficiary bank, meaning you know in real-time the message has been delivered. Compared with SWIFT, you only know SWIFT has received the message in real-time.
If the beneficiary bank can't be contacted for what ever reason, the sending bank (FromBank) simply keeps on trying until the beneficiary bank (ToBank) are back online again.
The problem with DDoS is a valid concern, but given the banks Internet banking services are also accessed by the banks users via the Internet, they are already dependent on the Internet.
If you don't need real-time messaging and if cost nor complexity is a concern, then you probably won't find BankAPI interesting.
Worth noting that HN does already have that functionality on a domain-by-domain basis. Not sure which domains exactly, but in 30 seconds found examples for blogspot.com, pinboard.in and github.io (example links below)
This is a cool project, but considering how over-regulated banks are these days (at least in Europe) I think it's very unlikely that they would actually use this. Most bank software is still written in Cobol code that they have invested four decades into and are now too afraid to rewrite or even touch. So, specifying the requirements for an interbank message system would probably take them a few years already, and implementing it in a "proper" way -i.e. confirming to all their regulatory requirements- would take ages (also, they will probably already have a system for this in place).
That being said, I think for less regulated sectors of the industry this could be a very interesting project.
It's a really common misconception that "most bank software is still written in Cobol".
Of course it varies from bank to bank, and of course there's still some legacy systems on Cobol. But many banks run primarily Java [1] in their backend. They have to: besides the fact that Java is a much more productive language than Cobol, it's the only way you can actually hire people nowadays! No bank running "most software" on Cobol is sustainable. The supposed fear to rewrite or touch simply isn't real either: if a bank does not understand and therefore care enough for "most" of its infrastructure, it isn't a sustainable bank either. These large corporations tend to be as conservative as you can get, but they are not totally oblivious.
That doesn't mean there are some little used systems still running on ancient stuff. I once heard an anecdote (no way to verify if true) that the Dutch revenue service rehired 80 year olds because they were the only ones that understood how to program some of their old machines that were programmed using wires and knobs.
The financial services market was the first market that was primarily an IT market, and a lot of infrastructure was built up on stuff that is totally unfamiliar nowadays. There are places that will pay you a lot of money for programming in an ancient language.
[1]: It's interesting to think that Java will be the Cobol of next few decades. Although I've seen signs that Scala and even Clojure are entering the banking world as well, which is encouraging.
Interesting thoughts, I agree most banks won't change because they don't even think they have a problem. Although there are a few modern banks who actually do use Linux, PostgreSQL and modern programming languages (not COBOL). :-)
REXX was my first introduction to programming for a real production system (at a national bank). It was one of the few usually-available, general-purpose toolsets that you could pretty much rely on to be available for "hacking something together."
Fond memories of my REXX days, although I shudder to think of going back..
> This is a cool project, but considering how over-regulated banks are these days (at least in Europe) I think it's very unlikely that they would actually use this.
According to Trustly themselves, it is used by 45 banks spread out over 7 EU countries (Sweden, Finland, Denmark, Estonia, Poland, Italy and Spain): https://trustly.com/en/#map-holder
I used to work for one of the megabanks. The majority of their credit card processing is written in Fortran and runs on 20-30+ yr old mainframes. They don't dare touch it. "If it ain't broke..."
There are certain universities that teach Fortran specifically for companies like this; any student of Fortran has an automatic offer once they graduate.
Are you sure it was Fortran and not Cobol?
Normally Fortran was used for academic/math (ForTran stands for Formula Translation, Cobol in busines (Cobol stands for COmmon Business-Oriented Language).
Fortran found its way into finance because it was the programming language taught to engineers in school. (These were real engineers -- software engineers hadn't been invented yet.) If you hired them to build computer systems you got systems in Fortran unless you specified otherwise.
What is the point of this? Seems to me there'd be no problem in using 3072 bit RSA keys, which makes more sense given that the lowest security symmetrical encryption algorithm permitted for use is AES128, and the difficulty of breaking AES128 is roughly equivalent to breaking 3072 bit RSA.