Unneeded materials from other depository libraries can now be transferred to the Internet Archive. Under 44 USC § 1912, depository libraries may dispose of outdated material, but must first offer to transfer to nearby depository institutions.
Libraries are constantly bringing in new materials and very few are capable of constantly increasing in size to match. I believe national libraries like the Library of Congress tend not to weed, but they do have to offload material to satellite locations and storage facilities.
Stuff like the printed tax code of 1965 or Borland Pascal 1992 manual. Once you have it digitized it's a waste of space for libraries to have a physical copy because basically no one needs it.
The touch controller is generally connected to a MUX controlled by the security processor. When entering sensitive data (PIN/PANs), the touch controller output is routed directly to the security processor, bypassing any Android-derived OS responsible for the GUI.
And as a user, I have absolutely no way of distinguishing this from a device that had all secure features removed, and is running a random Android that proxies the NFC or chip data to a real reader, siphoning off what they can, while my PIN gets proxied by a human typing it into the real reader in real time. All I'd notice is a second or so of latency.
Do you have a way do make sure that a terminal with physical buttons is secure? To me, the touchscreen doesn't make the whole device inherently less secure.
As far as I understand, the whole system is designed to make replay attacks useless. PIN on its own doesn't allow you to make a transaction, neither does it in combination with a recorded conversation between the reader and the card during a successful transaction. There's some asymmetric cryptography involved with the private key stored in the chip on your card and every signed payload containing a random nonce.
The PIN and magstripe data alone (which I think can be replicated from a one-time read-only interaction with the chip) are enough to make payments in some cases.
If there are sufficiently few legitimate terminal types in circulation and the user is aware of it, anyone presenting a different terminal would be looked at with suspicion. With the status quo, I as the cardholder essentially have to assume that anything presented to me is likely legit, even if it looks like someone's homemade skimmer.
However, this still leaves the merchant. If they (the person handing me the terminal) aren't in on the scam, any tampering has to be non-obvious to them. AFAIK some places go as far as weighing the devices and regularly checking seals and serial numbers. VISA recommends checking twice daily https://busfin.colostate.edu/Forms/Merchant_Svcs/Visa_Securi...
Trying to tamper with a terminal with physical buttons would almost certainly require rewiring it physically, triggering tamper detection and rendering the terminal useless. So it would have to be swapped with a unit that looks identical despite being tampered, and functions well enough to not raise suspicion. I guess an attacker could hollow out a case and insert completely custom electronics, in theory, but that's quite a high bar (especially if it requires forging serialized seals).
On the touch-screen-with-insecure-Android, a software-only change on the insecure side (never actually initiating PIN entry mode, or only initiating it after the first attempt and "pin incorrect" message) should be enough to get the PIN, and an added NFC skimmer not connected to the other electronics could do the rest.
The devices also look cheaply made, distributed in small numbers, and I have my doubts about them having as many anti-tamper features as the most common terminals, although I might be wrong. If they have strong physical anti-tamper measures, and the software is hardened against software-based tampering, I think that they could, in theory, be comparably secure.
Magnetic stripes seem to only still be popular in the US. It always blows my mind just how insecure card payments are there. For small payments, like several dollars, they'll swipe your card in a reader attached to the POS system and that's it. No pin code, no nothing, you just get an SMS that your card was charged several seconds later. For larger payments they'll rely on entirely human-based confirmation methods like "sign the receipt" or "show your ID". I didn't even know this was a thing before I visited the US.
In Russia, where I'm from, I haven't swiped my card for at least a decade. Lately many places also started getting those square Android-based Sberbank terminals that don't even have the magstripe reader, only NFC and chip. Granted, our banking system has been effectively disconnected from most of the world since 2022, but I would be surprised if these aren't designed to accommodate MasterCard and Visa requirements for when they return. And skimmers are simply not a thing here any more. People get scammed through social engineering instead.
I also remember reading that magstripe transactions cost merchants more or something like that, precisely because they carry more risk because they only need static, easily copyable data.
Anyway, the point I'm making is that the threat model changes, and becomes much simpler at that, when transactions can't be made with static data. Because no matter what the scammer captures, even if that's the PIN and the complete data exchange with the card through NFC or the chip reader, they can't use that to make transactions. Obtaining the number, the expiration date, and the CVC is also unlikely to allow them to make online transactions because those need a second factor now. Except on Amazon. Amazon somehow manages to charge my card with just the number and the date, no CVC needed, and no 2fa code either.
Thinking about it a bit more, no, your argument about touchscreens doesn't make sense. The terminal OP looked at runs Linux on the "insecure" side, but the keypad is still passed through to that the same way the touchscreen would be passed through to the Android SoC, because it's used to navigate menus and enter the purchase amount. The Linux side would still send some sort of command to the CPU core that runs the "secure" OS to initiate PIN entry, and it could still just do what you describe.
Reading and listening to Mandarin was much less difficult than I expected. Good pronunciation was more challenging, but after working with a speech-language pathologist, my speech production is good enough that I'm rarely asked to repeat myself.
Trying to understand why the Nein Nines could happen. My first thought for a “fill” algorithm would be to just fill with zeros, and hence read out the pad, since it is going to be used up anyway. But I suppose that’s bad since if it did accidentally get re-used then that cyphertext would be fully compromised (versus say having two cyphertexts from the same pad to run a frequency analysis against). Another fill would be to add random data and pad against it, but then if your random data is flawed, you may still leak the OTP. So, I guess the actual algorithm must be derived from the OTP, but not padded with it? (Since if it were padded, there is no way to avoid a 9 digit). It just seems like zero or semi-random fill seems safer…
> My first thought for a “fill” algorithm would be to just fill with zeros, and hence read out the pad, since it is going to be used up anyway.
That also would use up the pad when there are no messages, requiring some secure way to get a new pad to the operatives when their existing pad is consumed. This is difficult enough (secure delivery of new pad) that it is unlikely that spy-HQ wishes to consume pad data for fill.
> But I suppose that’s bad since if it did accidentally get re-used then that cyphertext would be fully compromised
Yes, if they reused any part of any pad for more than one single message, they have compromised (and revealed) the contents of the reused pad messages. This is the other difficulty with OTP's. The OTP data must never be reused. Which is alo why spy-HQ would not want to use it (the OTP) up for the fill, because to avoid reuse then they have to get new pad material to the operatives in some secure way.
> So, I guess the actual algorithm must be derived from the OTP, but not padded with it?
The 'implication' of the article is that the fill is just random data (without using up any pad material). Possibly with the appropriate headers in place so that it looks indistinguishable from a read message in the same slot.
The further implication is that the Cuban station did something essentially like this:
for (count=0; count<20; count++) {
send(int(rand()*9));
}
With a rand() implementation that returned a number from zero to 1.0 exclusive of 1.0 and an int() implementation that merely truncated any fraction from the multiplication. With the result that 9 is never sent.
Even if it returned 1.0, that would still leave 9 being produced a _very_ small amount of the time (like 1 in 18 quintillion assuming the full range of a float mapped from 0.0-1.0). Even at 20 characters, 24 times a day, year round, you’d only see a 9 pop up once in every 100 trillion years or so.
Lots of ways to mess that up (`rand() % 9`?). I’m more surprised that nobody noticed for so long. It’s not like this was some subtle cryptographic bug that would have required deep analysis to catch… “you had one job”, and just glancing at the output was, evidentially, enough for a lot of other people to catch on.
that's kind of the beauty of the system. we actually have no way of knowing if it was just random fill.
maybe they were just random digits with an off by one error or some other problem with the symbol set missing one symbol.
or maybe the supposed fill messages can actually be cryptographically confirmed as authentic fill messages via some clever scheme (that the implementation of turned out to be buggy).
or maybe someone from some sort of field operations chain of command just slammed the table and said "my people are tired of trying to decrypt fill messages, i don't care, just cut the nines out so the field agents know if there's a message."
It says in the article me that the spies would decrypt and verify a header before moving on to the main message. Presumably the fill messages would simply not have a valid header, or it would have a special header that indicated it was a fill message.
According to the Matt Blaze article, the Radio Havana numbers station sends 3 messages per hour. At the start of the transmission, three 5-digit message identifiers are sent for the 3 messages to be transmitted.
My guess is there's some cryptographic structure to these indicators that tells agents if the messages are for them, so they can shut down their listening early if none of the three messages are for them. If it were otherwise, I would expect each indicator group to be before (or inserted at a secret agent-specific offset within each message) each message. If you listen to the mp3 recording linked from Matt's article, you'll notice that the three indicator groups are repeated before the actual messages begin. Presumably the repetition is to guard against the indicator groups being garbled, since if the indicator group gets garbled, the whole message is garbled. On the other hand, a garbled regular message group would only result in a few characters of the plaintext being garbled.
Placing the indicator groups at constant (and secret) per-agent offsets within the messages has been known since at least WWII. In the case of an OTP, having a secret offset of the indicator group makes it harder to detect if the fatal error of pad reuse has been made. In the case of other ciphers, making the location of the indicator group secret also complicates cryptanalysis.
It wouldn't make sense to separate out the indicator groups like that unless it provides some operational advantage to offset the small cryptoanalytic toehold provided by highlighting the indicator groups. Allowing agents to shut down their listening early is the most obvious advantage I can think of.
The simplest cryptographic structure (and devoid of bias if the OTP is devoid of bias) would be to simply have the indicator group be the first 5-digit group for the next page in the OTP. The agent would need to check the next several pages of their OTP to verify they hadn't missed any messages. Encrypted headers within the messages could be used to handle the rare cases of collisions across agents, rather than introduce extra stucture (weaknesses!) to prevent any two agents from ever having duplicate indicator groups across their next few pages of OTP material.
Of course, it is also possible that these repeated indicator groups at the start of the transmission are just decoys and the real indicator groups are somehow hidden within the messages in some way that provides redundancy without revealing which groups are the indicator groups. Maybe the first three groups of the OTP page are placed at 3 constant offsets within the message or something.
But, my guess is that these repeated indicator groups at the start of the transmission really are there to let the agents know that they can shut down their listening early when there are no messages for them.
I didn't mean to imply that. What I meant to imply is that at the beginning of their appointed hour, they tune in to see if they have a message that day/week.
However don't you think your own explanation of improving security against accidental key reuse could be the explanation, with the repetition being there only for that purpose?
The extra protection against key reuse requires the attacker to be uncertain of which group is the indicator group. Placing indicator groups at the beginning of the broadcast would prevent that, but would allow agents to better avoid detection by minimizing the time they need to listen.
