The cryptocurrency world has been the scene of some *wild* stuff lately… and a recent lawsuit filed by IRA Financial Trust against Winkelvossian crypto exchange Gemini is no exception. Before I get into my take on this interesting tale, let me point out that all of the information in this post is taken from IRA Financial’s complaint against Gemini and is thus meant to persuade some future jury to award them a mega (actual fiat) dollar settlement and we have not really heard Gemini’s side of this yet. Nonetheless, there are some interesting questions to ponder.
IRA Financial Trust helps people administer their retirement savings accounts and decided to get in on the crypto boom by allowing their account holders to put their funds into cryptocurrency. (Personally, I would put my retirement funds into unregistered Belizean penny stocks before crypto, but that’s not the issue here).
IRA Financial signed a contract with Gemini to run the crypto side of things and hold their customers’ coins for them, based on Gemini’s reputation and assurances around the high level of security measures taken by the company.
One fine day, the police show up at IRA Financial’s offices with a SWAT team after having been told that a kidnapping was in progress. (Spoiler alert – no kidnapping was in progress). While all of this is going on, persons unknown take advantage of the confusion to use an API key (a kind of password which allows Application Program Interfaces – the language used by computers to talk to each other – to do security sensitive things) to transfer funds from many of IRA Financial’s Gemini accounts into a single Gemini account and then transfer that money out to parts unknown. In all, $36M was alleged to have been stolen.
IRA Financial claims that they were never given a phone number to call to report security issues and that when they sent repeated emails, Gemini’s response was delayed and partial, allowing the attackers more time to abscond with the funds.
One of the key claims in the complaint focuses on that API key – IRA Financial claims it was “pressured” by Gemini to use the API, that Gemini never explained the potential power of the API key to transfer funds amongst accounts, and that Gemini did not take proper steps to secure the API key when providing it to IRA Financial. It sounds like the attack was enabled, at least in part, by someone getting that API key (maybe by gaining access to their email and snarfing it from there?) and I am sure that one of the major questions in the jury’s mind is going to be whether the disclosure of the key was the result of negligence on the part of IRA Financial, Gemini, or a combination of the two.
The API design also seems to be called into question – the API key gave access to a master account with all of IRA Financial’s customers’ funds held in sub accounts. With the API key, it was possible to transfer funds from one sub account to another (with no second factor required) and IRA Financial sees this as a design flaw in the API, since in their business model, these kinds of transfers are not needed. Another question for the jury to ponder.
There’s more here – questions about hot wallet versus cold wallet storage claims and the veracity of Gemini’s marketing regarding its security measures.
I feel really sorry for any potential jury who has to figure this one out – there are some really complex and thorny security questions to be answered, and I am sure that if this goes to trial, each side will bring expert witnesses who will swear on a stack of bibles that it was all the other side’s fault. I’d really enjoy being one of the people trying to unpick this puzzle, but our jury system will ensure that the people selected to do so are totally unequipped for the challenge. I have a feeling that both sides will see the risk of putting this case in front of a jury of average folks and it will result in a settlement.
Nonetheless, this complaint is a great read for security professionals – it is thought provoking on a number of topics: the security claims that companies make in their marketing materials, having a process in place to deal with security breaches, designing APIs to be secure and adapted to business purposes, and communication of important security information to customers. Again, the presentation is very one sided (that’s the job of this document) but the questions raised are worth considering and trying to draw some lessons from.