No. The attacker doesn’t need to do anything more than to position himself in the right place in line. No millisecond accuracy needed, it’s a series of discrete events.
I brought up a compromised TSA agent as one way to work backwards to calculate the Random seed, but this actually turned out to be unneeded because the seed resets every time.
Instead I think the simplest solution is to have a virus on the tablet that could control when exactly the click event took place. So the TSA agent clicks to make an arrow, but the actual event wouldn’t fire for n milliseconds after, in order to select the seed and force a left or right arrow. Since we’re only interested in producing one of two different outcomes, and we can look up the result of any given seed, we would probably only have to wait a maximum of five or six milliseconds to be sure of getting the arrow we wanted, which would be completely unnoticeable to the user.
So now we have an app that can create any pattern of arrows we like. You can exploit that any number of ways, but one simple way would be to have a repeating pattern, memorizable by the attacker. LLRRRLRLLR. A TSA agent isn’t going to notice that it’s repeating (and it could be set to do so only between specific times). Now your attacker hangs back for just a moment, works out what part of the cycle it’s in, and puts himself in the line to land in that block of three R’s, giving himself a high chance of hitting it even if the line order gets messed up. And if it’s messed up too much, he exits to empty his water bottle or something.
Once you control the sequence of arrows, an attack is trivial.
So, yes, I think they do care about whether their “random” function is properly implemented.
better than a virus: impersonate the time sync server. i don’t know the details of ntp but if you could guarantee a reset within some time frame, you might be able to corral the generator. you don’t get “more” random by simply reseting the seed each time.
@Daaksyde mentioned games: ive seen more than enough good randoms badly modulused to create noticable patterns in output. it really can matter what algorithm you use, and how you use it.
[quote=“SamSam, post:41, topic:76138”]
I think the simplest solution is to have a virus on the tablet[/quote]
Yes, but at that point, the random algorithm/function that the programmer chose, and its result, are irrelevant because the virus could switch it out with its own code/data. (as well as what you’ve described)
This is true. It’s a reason people say use the vetted libraries for cryptography instead of rolling your own. I’m an outlier in thinking that there’s a reasonable need for more variety in cryptography, but for most non-cryptographic uses of randomizers, creating a new random algorithm is overkill and likely to be buggy. For that I believe in just using the existing library functions.
ahh… but! if the seed was distributed once per day in a secure manner, the choices could be vetted at intervals at the end of each lane; the server replaying the same sequence. that’d be a great way to verify the software and the tsa personnel. ( and that would exclude resetting the seed on a ms basis. )
Not so, because I’m assuming that they are at least competent enough to have a locked down app, one that probably connects to a server to confirm that it’s running with valid keys. (Something, again, that this 10-minute video doesn’t demonstrate). Otherwise, as you say, the whole thing is pointless. But… really really pointless at that point.
The beauty of the delayed-click virus (or @gatto’s fake time-sync server, but I think that’s much harder), is that it leaves the app entirely alone. All self-verification checks can pass, and any communication with a secure server works as expected. It’s entirely outside the app, and exploiting a stupid weakness made by the designer.
