Start at the Prologue and First Chapter here
Crypto shadowed Frank’s latest interactions at the GFBS section of GitHub and considered what to do next. Nothing that Frank had done to date suggested that he was on the way – yet – to discovering anything of concern. But the possibility of his doing so was not zero. Happily, it was time for Crypto to launch the next step in his plan, which was to raise the perception in the marketplace that the GFBS blockchain was far more secure than any other alternative. That should reassure Adversego and his overseers as well.
But there was no need to act in haste. Only methodical care and an almost fanatical attention to detail had allowed Crypto to remain unknown for over a decade. Over time, a slow, careful approach had become second nature to him; a source of pride rather than impatience at the extra time and effort such care required. But it was clearly time to act.
He began by browsing on to the Tor Network, the most popular manhole through which anyone could drop into the Internet netherworld commonly referred to as the Dark Web. Dark, because unlike the everyday Web, its contents were invisible to the robotic crawlers that index the pages accessible to browsers like Chrome and Firefox. Dark, too, because access points like Tor provide almost impenetrable anonymity. Any message you wished to send was encrypted, and then encrypted again, down through the multiple layers of scrambling that had yielded the TOR acronym – short for The Onion Router.
Once logged in, Crypto gained access to thousands of routers maintained by TOR volunteers all over the world. Not only could you send or post a massively encrypted email, chat message, or file wherever you wished, but your identity was separated from the message or document itself. When you hit the “send” command, each was sent caroming randomly throughout the vast expanse of the Dark Web until eventually they were reunited at the intended destination and decrypted by the intended recipient. It was a wonderful system for anyone anxious to protect their on-line anonymity – perhaps someone bravely acting as a whistleblower. It was even more useful to someone engaged in illicit activities, whether it be drug dealing, fraud, or – in this case – facilitating the theft of alt coins.
Still, one had to be careful. The Tor technology was powerful indeed, but its creation and further development had been funded primarily by the U.S. Department of Naval Research, and by that venerable skunkworks of the U.S. Department of Defense popularly known as DARPA, short for the Defense Advanced Research Projects Agency. There was reason to believe that there might be weaknesses built into TOR that only the U.S. government knew how to exploit.
But Crypto felt comfortable enough engaging in the type of quick hit and run activities he had in mind for today. It took only minutes to load his offer to several sites where zero-day exploits were bought and sold. Zero day exploits described ways to take advantage of a vulnerability in a program that until then had been unknown. Such a software flaw was hence still at “zero days” from the time the honest world learned of its existence.
If the vulnerability was bought by a criminal, it would soon be used to launch an attack. But it might instead be bought on the Dark Web by a government agency, like Israel’s Mossad or the National Security Agency (NSA), in the United States. Such agencies regularly bought zero day exploits to hold in reserve against the day when they wished to infiltrate or compromise a foreign government or criminal enterprise. All of these buyers bid against each other on the Dark Web until the highest bidder won.
But not this time. Crypto was an anarchist, not a capitalist. He wanted to make sure that black hats, not governments, purchased his vulnerabilities. So he priced his vulnerabilities high enough to avoid suspicion, but not so high as to discourage purchase by criminals all over the world. And he offered them to anyone for a price, and not just to a single successful bidder.
The profits were irrelevant in any case. They were nothing to Crypto compared to the risk of discovery. Despite the fact that the blockchain enabled payments to be made and received anonymously, Crypto directed the payments to a brand-new blockchain wallet he would never access again.
Half an hour after logging on, his work was finished. All that was left was to watch the fun begin.
* * *
Josh Peabody was hosting a cocktail party at his office for CryptoBoom’s! largest investors when the telephone in his pocket started going berserk. He ignored it for most of a minute, because he was speaking to the chairman of the fund’s Valuation Committee – the Committee that decided on the value of the fund’s portfolio, and therefore the amount upon which Peabody’s management fee would be calculated. But eventually the angry vibrations began to unsettle him. That degree of unease was nothing compared to the sensation he felt when he looked at the phone’s screen and felt the bottom of his stomach hit the floor. With a sick smile, he excused himself and left the room as rapidly as he could without being obvious.
Once in the hallway, he dashed to his office and opened up an exchange program. To his horror, the price of Tabbies was plummeting on the breaking news that more than one half of the entire issuance – including CryptoBoom!’s entire position in the alt coin – had been stolen.
* * *
Frank was once again sitting in the main conference room on the sixty-fifth floor of First Manhattan Bank. At the head of the table sat a grim-faced Executive Chairman of the Board, impatiently waiting for an update on the wave of assaults that had nearly destroyed the alt coin markets over the preceding forty-eight hours. To varying degrees, everyone around the table looked shell-shocked. The financial carnage was severe.
The door opened and the receptionist ushered in the last anticipated attendee, a middle-aged man wearing the expensively-tailored uniform of someone who advises similarly dressed people. Nukem nodded to him and immediately began speaking.
“All right, everybody. Let me introduce you to Henry Dana, from Bingham & Gould, the analytics firm advising us on alt coin markets. Greg, we’re all waiting to hear what you have to say.”
“Hello everyone,” the analyst said. “I’m sure you’ve all read the public accounts of the chaos roiling the alt coin markets over the last two days. What I’ll try to do today is quantify the actual losses to date and provide our view on the possible short and long-term impacts on BankCoin.
“Let’s start with the high-level numbers. The attackers hit a total of six cryptocurrencies, including Bitcoin and the three alt coins with the next highest market value, other than BankCoin. They made off with approximately seven to eleven percent of the total number of each of those alt coins currently on the market, depending on which coin we’re talking about. Taken together, the stolen coins have an aggregate value of over twenty billion dollars based on their trading values at the time of the attacks. That’s a truly staggering amount – far higher than all previous coin thefts combined.
“But that’s just the tip of the iceberg, at least on a temporary basis. Following the cascade of news breaks revealing one attack after the other, the market valuations of all major alt coins plunged, dropping from fifty-six to eighty-two percent, again, depending on the coin. That amounts to a further loss of over one hundred fifty billion dollars of value.”
A hand went up. “Yes? Dana asked.
“Why was the impact so great on coins that hadn’t been hit. That’s new.”
“You’re correct. The difference is that in previous theft situations, only one type of coin was affected. This time, six were hit. The market presumably decided that if six different coins could be hit all at once, every other coin must be just as vulnerable. So a lot of people obviously decided to move some or all of their coin investments out of the blockchain ecosystem and into traditional investment alternatives, like stocks, bonds, or even cash, at least temporarily.
“At its lowest point, the main alt coin index dropped below twenty-seven percent of its pre-attack value. It came back about ten percent when no new attacks occurred over a twenty-four hour period, but it’s still off by more than sixty-four percent. Assuming no new attacks occur, we expect it to gradually move up, but that’s about the most we can say for now.”
“Happily,” Cronin interjected, “The value of BankCoin hasn’t been affected at all, since it’s pegged to the dollar. And our blockchain remains secure. Can you confirm that, Dirk?”
“This is correct,” Delhohn said solemnly. Frank, dressed to blend in with the rest of the suits crowding the table, noted that Audrey Addams had not yet succeeded in paper-dolling the crotchety Dane.
“Just as I would expect,” Delhohn continued, “The GFBS blockchain is set up in a completely different manner than any other blockchain. We are a closed system. This is fundamental to maintaining its security.”
“Can you tell whether an attempt was made?” Nukem asked.
“I have seen no evidence that any attack was launched against BankCoin.”
To Frank’s embarrassment and Delhohn’s obvious annoyance, Nukem turned to Frank. “Do you agree?”
“I do,” Frank said. “We scan the bank’s blockchain infrastructure constantly. And by agreement with the other banks, a third-party security assessor runs vigorous penetration tests against each bank’s blockchain host computers every week. We’ve seen no increase in hostile activity beyond the usual baseline of probing we experience.”
“Well, thank God for that,” Nukem said. “Here’s hoping it stays that way.”
Sure, it was great that the BankCoin blockchain had been spared, Frank thought. But if Delhohn was right, why had the attacker tried to breach every major coin except BankCoin? Did the differences between the private BankCoin blockchain and the various public systems provide the answer? Or were the attackers simply saving BankCoin for a later day?
That possibility deeply troubled Frank. And another thing did, too: not a single attack had been launched at the edge of the crypto-currency system, as had usually been the case with past attacks. Instead of hitting exchanges and wallets, the attackers had exploited flaws in the blockchains themselves. That was truly unnerving, as it struck at the very core of the blockchain concept itself.
It also highlighted the fact that a supposed blockchain strength could also be a weakness. Normally, a bank was the sole repository of the records relating to its assets. Tamper with them at a single location, and you could steal those assets. With a blockchain, the equivalent records – and the supporting software – could be found on hundreds, or even thousands of computers. Nobody could attack all of those computers at the same time, and the blockchain itself could not be changed except by mutual agreement of a majority of the owners of those computers.
That sounded good, except that any Tom, Dick or Harry with a powerful enough machine could decide to join the club. Worse, since there was no central authority, there was also no minimum level of security required. If some Dick wanted to set his password as “password,” or “123456,” there was no one to stop him. It was truly chilling. And since each such developer hosted a copy of the blockchain itself, each represented a point at which a flaw in the blockchain could be exploited.
“So, what do you think about all this, Frank?”
Frank jolted back to attention. Horace Nukem, as well as everyone else, was looking straight at him.
Frank had no idea what had most recently been said, so he ran for what he hoped was safe ground. “It’s certainly a credit to Dirk and the rest of the GFBS coders that BankCoin wasn’t hit. That said, the fact that we weren’t breached this time is no reason to be complacent. Even if we’re more secure today than the competition, we can assume the best of the other alt coin projects will up their security game to plug the gaps, or they’ll be left behind. That means that over time we’ll become a more attractive target, unless we maintain our security lead.”
“Nonsense!” Delhohn snorted, to Frank’s surprise. “You are all looking – what is your saying – the gift mule in the mouth. There is a reason that every major alt coin scheme was hit except BankCoin. That reason is that BankCoin is far more secure. It was designed with security against theft as its highest priority, rather than as an afterthought, like the other coin blockchains. Instead of sitting here wringing our hands over the future, we should be promoting the fact that BankCoin is the only secure blockchain in existence. What are we waiting for?”
Cronin, being no fool, seized on the lifeline thrown from such an unexpected quarter. “Dirk is right, Horace. These attacks are an opportunity, not a disaster. We should be doing exactly what he says. Not in an inappropriate way, of course. But we shouldn’t be shy about pointing out the fact that not one penny of First Bank of Manhattan assets was stolen, nor was the value of any customer assets compromised.”
Nukem paused and frowned. “Fair enough. I’m as happy as the next man to ride a gift horse for all it’s worth. But I’m also with Frank. If anyone gets complacent about blockchain security, they’ll be doing it somewhere else if I find out. And I want a weekly update on everything we can find out about these attacks – how they were carried out, who may be behind them, and what the vulnerabilities were. That’s all for today.”
* * *
An exhausted Josh Peabody turned off his computer and slumped back in the office chair he’d occupied for the last thirty-six hours. Exhausted, but triumphant. It was good to see he could still pull out the old magic when he needed to. Truth to tell, he’d been coasting for years now, taking advantage of investment waves that anyone with adequate savvy and inadequate principles could ride to a handsome profit. But pulling off the thousands of complicated puts, calls and swaps he’d just executed in the face of plummeting alt coin prices had taken real skill, not to mention balls. Now that the dust had settled, he could congratulate himself on managing to notch a small profit for CryptoBoom! And he’d been smart enough to insist on cash for all his previous alt coin underwriting deals.
Yes, he thought, rolling down his sleeves and watching the first light of dawn coloring the coastal mountains in the distance, I do believe that Elvis has reentered the building.
* * *
Author’s Notes for this Week: We’re starting to get into the meat of the cybersecurity plot now, which is always an interesting journey for someone with a BA in history who’s never written a line of code in his life. I have, however, represented coders for my entire professional career, and done a lot of reading besides. The result is what you might think of as a symbolic, or metaphorical level of understanding of the technical nuts and bolts, and that’s a good level to think in when you’re writing light reading for non-technical readers. The trick, of course, is to keep it detailed and credible enough to appeal to technical readers while not losing the rest. One thing that each of you, as readers, can do to help me out a lot is to tell me if there’s every anything you can’t follow, on the one hand, or that’s technically wrong, on the other.
While we’re on the topic of technology, let me bring you into my thinking about how Frank will eventually figure out that something’s going on with BankCoin. My thought is that Frank will set up a duplicate of the BankCoin blockchain for experimental purposes, and in order to get familiar with the code, he won’t just copy what’s there already. Instead, he’ll compile a copy from the source code instead.
For those of you who don’t have a clue what I’m talking about, here’s the distinction. “Object” or “machine” code is the ones and zeros that you think of when you think about computer programs. It’s also what you receive when you buy software. But even to a skilled programmer, one and zeros are tough to make sense of. What they usually work with instead is something called “source code,” which is words, symbols and other objects you can find on a computer keyboard. Here’s a sample of source code from the MIDI music player that you’ve likely used:
Still kind of incomprehensible to a non-programmer, but you can see how someone who knew what they were doing could make a heck of a lot more sense out of this than 100100 101010 111100 and so on. Developers write code like this on their laptop and then use a tool called a compiler to convert it into object code, which is what a computer can “execute.”
Now back to our story, and here’s where I’m going to ask for some help from any of you that are programmers. I’m assuming that compilers aren’t perfect, and that a programmer would still have to do some debugging in order to get a program running perfectly. That’s why Frank would want to start with the source code, as in the process of debugging the BankCoin blockchain he’ll get a feel for how all the pieces fit together.
So, here’s my question: am I right in assuming that compilers aren’t perfect? Knowing the answer to this would be very helpful to me. If the answer’s yes, I’m off to the races. If I’m wrong, then back to the drawing board.
Next week: I believe that next Saturday you’ll learn the first half of Crypto’s back story. However, I’m now writing about a half dozen separate threads – Frank’s investigation, Crypto’s offensive and defensive efforts, the kickoff of the new CIA task force, Frank’s war of wits with Fang, and several more besides. At this stage in the book I therefore need to decide in which order to start introducing these multiple building blocks to create an effective narrative. Later on, I may reshuffle the deck to make the story evolve more naturally depending on how the plot is coming together. Often, I’ll think of a whole new thread half way through the book. So whichever way I come out next week, don’t be surprised in the final book if something different happens next.
As a programmer with experience in FLOSS development think it unlikely that the BankCoin source code would fail to build on Frank’s machine, unless Frank is using an unusual OS and/or compiler. Compilers aren’t perfect, but they are pretty close, and the things they fail at are very hard to predict or understand. Nowadays blaming the compiler when your code doesn’t work is very unlikely to be correct.
There are sometimes issues with optimizers that can change what a program does because the original code made use of “undefined behavior” (UB). The code may have worked fine on one compiler or even on several older compilers, but the language standard (usually C or C++) actually lets compilers do anything (i.e. whatever’s most convenient) when fed code that relies on UB. Hiding UB in older code might not be too hard, but modern compilers can find and report such code, so relying on it in the longer term is probably not wise. Java (mentioned below) doesn’t have UB to my knowledge though so I wouldn’t rely on that.
However I wonder if you were thinking about the issues raised in Ken Thompson’s lecture “Reflections on Trusting Trust” https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf where the Trojan horse isn’t present in the source code being compiled at all, but is built into the compiler itself (and the compiler Trojan recognizes when it is compiling a new copy of the compiler and inserts a copy of itself into the new compiler executable, so the source code for the Trojan is never visible once it has been embedded the first time).
That quite famous idea would be a plausible way for Crypto to infiltrate his code into BankCoin. Now one solution to Thompson’s problem is to use a different compiler to compile your compiler, but for a language like Java (very common in businesses now) there aren’t many compilers for that. If Crypto had worked for Sun when the early Java compilers were written and maybe moved to IBM when they were developing their own it’s conceivable that he could have pulled this off. The Trojan would probably be downloading its own code from the internet nowadays because the whole “recognize you’re compiling the compiler” thing would need updating occasionally as new features get added to it, but I think this approach would still be a plausible way to infiltrate the BankCoin code.
HTH,
– Andrew
Andrew, thank you very much indeed for such a thorough and helpful comment – this is great. You’re giving me too much credit for thinking I might be aware of the Thompson lecture, although I might have thought of the “hack the compiler instead” approach eventually on my own (which might be example of me giving myself too much credit).
I like your idea a lot, although I’ll need to think through what would happen next. I guess Frank could have a favorite compiler, but then we need to assume that it would compile the source properly, and all would be good, and he’d still be in ignorance.
Let me go back one step in the original plot plan and see whether there’s a different way to have Frank catch on. My original thought was simply that there would be a piece of source code missing which contained the Trojan, generating something for Frank to stumble on, reverse engineer, and then realize what was afoot.
That meant that I needed to generate a scenario where he would notice that there were a few modules of undocumentend code, which led me to think about starting with a binary rather than a source code copy of BankCoin, and then a failure to run, and then noticing that there was more binary than source.
Is there a scenario you can think of where Frank would notice that there was too little source code that would get me where I want Frank to do?
If you are thinking of Thompson’s Trusting Trust attack, you should look at its general solution from David A Wheeler’s thesis work:
David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) – Countering Trojan Horse attacks on Compilers
https://www.dwheeler.com/trusting-trust/
Here is a more accessible discussion on Bruce Schneier’s blog:
Countering “Trusting Trust”
https://www.schneier.com/blog/archives/2006/01/countering_trus.html
If you are thinking of Thompson’s Trusting Trust attack, you should look
at its general solution from David A Wheeler’s thesis work:
David A. Wheeler’s Page on Fully Countering Trusting Trust through
Diverse Double-Compiling (DDC) – Countering Trojan Horse attacks on
Compilers
https://www.dwheeler.com/trusting-trust/
Here is a more accessible discussion on Bruce Schneier’s blog:
Countering “Trusting Trust”
https://www.schneier.com/blog/archives/2006/01/countering_trus.html
“Is there a scenario you can think of where Frank would notice that there was too little source code that would get me where I want Frank to do?”
What Crypto has to do ist to subvert the hash encoding such that it is possible to create “collisions” at will. That is, someone could change a record in the block chain without changing the unique message digest that identifies that record. To be able to do that, Crypto would have to subvert the reference implementations and libraries used by all compilers.
A more devious approach is to infect not the compilers, but the micro code or chip hardware on which the algorithms run.
That is, trusting trust in Intel or GPU processors.
Trusting Trust attack
Here is an article about a microcode attack (from the CCC conference):
34C3: HACKING INTO A CPU’S MICROCODE
https://hackaday.com/2017/12/28/34c3-hacking-into-a-cpus-microcode/
An older explanation of hardware CPU attacks from Joanna Rutkowska:
Trusting Hardware
http://theinvisiblethings.blogspot.nl/2009/03/trusting-hardware.html
If you want to get more information about the most insidious attacks, follow Joanna Rutkowska’s writings and presentations.
“Is there a scenario you can think of where Frank would notice that there was too little source code that would get me where I want Frank to do?”
Maybe others can correct my mistakes, but it could look something like this:
First, it is not clear why the changed blocks get the same hashes. Then someone (Frank?) finds out that the attacks involved some hidden magical markers in the blocks to trigger the change (e.g., certain wallet addresses? In combination with certain amounts?). After finding out that the message digests/hashes have are unreliable in the changed blocks, Frank would test all the compilers, finding the same hash collisions everywhere. Then he would start running the code in different computers until he hits on an old/special CPU that does not show this behaviour.
Rob (replying to all three of your comments here),
Thanks for the links and to all the good thoughts. Re this one, I would have thought that any change within a block would inevitably change the hash in the next block, unless by “collisions” that’s what you mean – with collisions going up the chain so that they are still linked. That, however, would create a fork that the other nodes would vote down, right?
In any event, I should clarify that what I was referring to was the source code of the program that creates and hosts the blockchain, rather than the source code for each block. I don’t want to give away too much of the plot, but if you’d like to contact me by email I’d be delighted to tell you what I have in mind and see what you think.
Lastly, in the small world department, I know David via email as each of us were part of the Great ODF/OOXML Wars of more than a decade ago.
“In any event, I should clarify that what I was referring to was the source code of the program that creates and hosts the blockchain, rather than the source code for each block.”
That would be the program that checks the integrity of the block chain? That is an obvious target.
That could indeed be through a Trusted Trust like attack both in the compilers, as well as in the hardware. This is such a basic feature of the coins that the number of independent implementations in active use will be small. Also, it seems the bitcoin miners and exchanges will source their hardware from the same suppliers. For CPUs, I suspect this will be Intel or AMD. For mining riggs, their are only half a dozen of suppliers using Asics. I know not enough about this world to know what the possibilities here are.
“He began by opening a new account on the Tor Network,”
In what way do you log into the Tor network? You only need to use a suitable browser to traverse it or visit hidden services, i.e., those with a URL ending in .onion.
You might be required to log into the individual hidden services, but not the Tor network.
And thanks again, Rob. I was making an assumption here, which is obviously always a dangerous thing to do. I’ll make that correction now.
If you are thinking of Thompson’s Trusting Trust attack, you should look at its general solution from David A Wheeler’s thesis work:
David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) – Countering Trojan Horse attacks on Compilers
https://www.dwheeler.com/trusting-trust/
Here is a more accessible discussion on Bruce Schneier’s blog:
Countering “Trusting Trust”
https://www.schneier.com/blog/archives/2006/01/countering_trus.html
(replies are disappearing, new try)
If you are thinking of Thompson’s Trusting Trust attack, you should look at its general solution from David A Wheeler’s thesis work:
David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) – Countering Trojan Horse attacks on Compilers
https://www.dwheeler.com/trusting-trust/
Here is a more accessible discussion on Bruce Schneier’s blog:
Countering “Trusting Trust”
https://www.schneier.com/blog/archives/2006/01/countering_trus.html
Hi Andy, sorry for the delay replying…
I suggest that Frank wouldn’t find out by noticing the difference between the source and binary size, but he might notice if his compiler starts accessing strange websites when it compiles this code. Frank could have his computer set up inside a network environment that watches all traffic going in and out, and maybe he even has honeypots set up to trap intruder code that tries to access places he doesn’t normally visit. While building the BankCoin software one of his monitors gets tripped (because the compiler’s trojan recognizes the source code but doesn’t know how to infect latest version of that code, so it is fetching the appropriate trojan payload for it). Frank would then investigate what’s going on from there (maybe throw in some Heisenbug behavior if you want to stretch that out a bit and make it harder for him to track down).
The Bruce Schneier blog that Rob pointed to would be a way for Frank to prove that his compiler is infected, although it might be too complicated to describe in the story.
– Andrew
Andrew, that’s an intriguing idea, although I do think it would be a challenge to explain in a way that would be both clear as well as hold a reader’s interest.
My challenge here is to come up with a convincing story arc for Frank as the cyber detective – that’s the main story line of the book, although obviously I like to add a lot of other interesting aspects. That’s in part to make it a more interesting read, but also because the detective arc would otherwise only support a story rather than a book.
In a murder mystery, the particular issue we’re talking about here doesn’t exist, because the story starts with a dead body. In each of my prior books, more or less the same things happened: either there were ongoing attacks, or someone within the government had become aware of activity that indicated a hack, which Frank then had to then figure out and thwart.
Here I’ve set myself a different and more difficult problem – there is, and likely will be, no direct evidence of a hack of the particular platform – BankCoin – that Frank is tasked with protecting.
In other words, Frank has to find the dog that does not bark.
That’s a big part of the arc, so I need to come up with a way that doesn’t just work from an IT point of view, but is easy to follow, and finally dramatic and step-wise, so it’s not just an aha! Your suggestion nails two of those – it works, and it’s detailed and dramatic – you’ve got good suggestions there to make it so. If I can figure out a way to simplify it in the telling, it could be a keeper, and I’ll give it some thought – thanks.
“Here I’ve set myself a different and more difficult problem – there is, and likely will be, no direct evidence of a hack of the particular platform – BankCoin – that Frank is tasked with protecting. ”
There is a thing that is going around in security circles that might be useful. It has long been feared that the executable programs that we download and install might not actually be compiled from the source code that we see. As most people will not do their own compiling, this is a genuine problem. It was a big question hanging over TrueCrypt at the time and also Tor.
The solution is called a “deterministic build”. In most programs, you get a different executable every time you do a compilation. That is because the compiler adds local directory names, language settings, date strings and statistics into the executable that differ between compilations. In security critical applications, the coders will try to ensure that the executable that comes out of the compilations is bit for bit identical every time. That way, ever one can check whether the executable that is distributed has not been tampered with by building from source. That should not be a problem to explain.
In the bankcoin case, every executable will be tampered with in the same way, so they will all pass the test. However, we can understand that Frank will do things his own way, on a different computer using different tools. Somehow, he messes up and his version does not contain the extra module, or a garbled version. Say, he once build his own compilers in a non-standard way. So Frank feels he is doing something wrong, wants to safe face or whatever, and will start to reassemble and rebuild his tools to get the compilation right. He then might check his tools (like David’s Diverse cross-compilation) and find out that his compilers do not match up with those used by the project and that the difference amounts to a functional module.
That could be a line of story that might be explainable to lay persons. Also, it emphasizes that for security work, it really helps to engage outsiders.
Security – Lack of deterministic build to ensure that compiled TrueCrypt applications are compiled from unmodified source code (with XKCD cartoon)
https://forum.truecrypt.ch/t/security-lack-of-deterministic-build-to-ensure-that-compiled-truecrypt-applications-are-compiled-from-unmodified-source-code/204
https://en.wikipedia.org/wiki/Deterministic_compilation
Thanks, Rob – this is really helpful. I think I’m starting to see my through this now. I’m not 100% sure how I’ll present it (possibly dumbed down a bit, and possibly adding some thoughts from earlier comments), but I think I can construct something now. When I do, I’ll post it for everyone to throw rocks at till I get it right.
While waiting for the next chapter. Here are some links for readers who want to know more about the dangers of combing banks and blockchains.
Top 10 Mistakes in Enterprise Blockchain Projects
https://www.gartner.com/smarterwithgartner/top-10-mistakes-in-enterprise-blockchain-projects/
Why Banks Will Fail to Apply Blockchain Technology
https://cointelegraph.com/news/why-banks-will-fail-to-apply-blockchain-technology
Another article: http://longhash.com/news/8
Thanks; a good illustration that great walls still can’t keep all the invaders out.
https://phys.org/news/2018-05-banks-dont-weakest-link-blockchain.html#nRlv