![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Some thoughts on p2p security
Apr. 20th, 2006 11:23 amSecond Life, the sprawling hack that it is, has me thinking about multiuser systems lately, particularly how to do them better. One really cool thing would be to have peer-to-peer spaces. For a small group, that would be a huge improvement over the $200/mo Lindens want to maintain an island. Just connect to your local tracker, ala BT, and have all the room your slowest clients can cope with. It goes away when the last person leaves, or someone could save to disk. What could be simpler?
Well assuming you tackled the voluntary coherence issues, there is still no authority involved. It's peer-to-peer, so how could there be? Kinna confusing. ( Let me outline the situation... )
Now suppose our ever-enterprising Carol hacks apart her VM. The first thing she does is add an instruction to let her see all the objects and their data, particularly those in Sw. Then she uses that to inspect Bob's bank account, and is sorely disappointed because Bob is fresh out of funds. So she builds a camera situated in Sa, that lets her peek right into Alice and Bob's skybox. (Which, we suppose, is what he spent the money on—it is peppered with luxurious textures and neon poseballs. She makes a note to copy her favorites.)
I think it's very important to point out here that, while nobody can violate security (e.g. forge object pointers) inside the VM, with contemporary hardware it will always be possible to hack the OS, machine, security chips, etc etc... and therefore, data extraction is a problem. SL does in fact have the same issues, but LL has been hushed about it. Probably because people never seem to understand this, and love to get upset over it... but really, it's a big fat social problem IMHO, considering what little current tech can do against a very determined Carol.
The solution I think is to use a whitelist (challenge-response), and not to have your skybox, or your banking, in public space (plain sight). Just RL common sense, there. But, but, I'm really getting off track here. The problem I wanted to talk about, and solve, is something different and much worse than peeping toms.
So while I was rambling, Carol has advanced her plans for Sw domination. Now she wants to abuse Alice and Bob's blissfully consistent view of the world. To do this requires no cracking whatsoever—just abuse of the protocol. All she needs to do is send two different messages or responses to Alice and Bob's Sw. The two copies will then slowly desync as the code takes different paths on each side. Obviously this is going to break, but to fix it, we need to know how.
( Somewhere along the line, Alice is going to try and effect the inconsistent world... Bob goes "LOLWTF!" )
Which points to a partial solution. What if we could make this situation arbitrarily likely (e.g. extremely likely) to happen with the smallest perturbation? Then we could roll back an arbitrarily short time to the past (requiring arbitrarily little RAM to store the difference), and nobody loses much work. It would also force Carol to run the exact same data and code, or else be found out, even if she runs a second cracked copy for herself.
Essentially, what I'm proposing, is the Halting Problem put to practical use. Message consistency proves with high probability that you ran the same code.
( The garbageman knows what you ate for dinner )
This would probably be integrated into some sort of "heartbeat" as a way to keep everyone sync'd within some bounded time. Note that it's also symmetrical. If Alice were to deliberately screw up her hash, Bob might think -she- strayed, and vice versa. To this point, any "accusation" is private. What to do if several peers disagree? Start voting people off the island? (Heheh, sorry. ^..^;)
The thing with voting is that it's only good if you play with several friends, or at least neutrals. But you don't want to play with cheaters anyway, I presume. At the least, you would discover something was up and take your toys elsewhere. The real problem, is if a large gang snuck up on your friends, and all of a sudden, voted you out. Sort of a DDoS... unless maybe you deliberately trusted your friends? Sticky issue.
Hrrrrmm. It's interesting to think about anyways. Let me know what I forgot. n..n
Well assuming you tackled the voluntary coherence issues, there is still no authority involved. It's peer-to-peer, so how could there be? Kinna confusing. ( Let me outline the situation... )
Now suppose our ever-enterprising Carol hacks apart her VM. The first thing she does is add an instruction to let her see all the objects and their data, particularly those in Sw. Then she uses that to inspect Bob's bank account, and is sorely disappointed because Bob is fresh out of funds. So she builds a camera situated in Sa, that lets her peek right into Alice and Bob's skybox. (Which, we suppose, is what he spent the money on—it is peppered with luxurious textures and neon poseballs. She makes a note to copy her favorites.)
I think it's very important to point out here that, while nobody can violate security (e.g. forge object pointers) inside the VM, with contemporary hardware it will always be possible to hack the OS, machine, security chips, etc etc... and therefore, data extraction is a problem. SL does in fact have the same issues, but LL has been hushed about it. Probably because people never seem to understand this, and love to get upset over it... but really, it's a big fat social problem IMHO, considering what little current tech can do against a very determined Carol.
The solution I think is to use a whitelist (challenge-response), and not to have your skybox, or your banking, in public space (plain sight). Just RL common sense, there. But, but, I'm really getting off track here. The problem I wanted to talk about, and solve, is something different and much worse than peeping toms.
So while I was rambling, Carol has advanced her plans for Sw domination. Now she wants to abuse Alice and Bob's blissfully consistent view of the world. To do this requires no cracking whatsoever—just abuse of the protocol. All she needs to do is send two different messages or responses to Alice and Bob's Sw. The two copies will then slowly desync as the code takes different paths on each side. Obviously this is going to break, but to fix it, we need to know how.
( Somewhere along the line, Alice is going to try and effect the inconsistent world... Bob goes "LOLWTF!" )
Which points to a partial solution. What if we could make this situation arbitrarily likely (e.g. extremely likely) to happen with the smallest perturbation? Then we could roll back an arbitrarily short time to the past (requiring arbitrarily little RAM to store the difference), and nobody loses much work. It would also force Carol to run the exact same data and code, or else be found out, even if she runs a second cracked copy for herself.
Essentially, what I'm proposing, is the Halting Problem put to practical use. Message consistency proves with high probability that you ran the same code.
( The garbageman knows what you ate for dinner )
This would probably be integrated into some sort of "heartbeat" as a way to keep everyone sync'd within some bounded time. Note that it's also symmetrical. If Alice were to deliberately screw up her hash, Bob might think -she- strayed, and vice versa. To this point, any "accusation" is private. What to do if several peers disagree? Start voting people off the island? (Heheh, sorry. ^..^;)
The thing with voting is that it's only good if you play with several friends, or at least neutrals. But you don't want to play with cheaters anyway, I presume. At the least, you would discover something was up and take your toys elsewhere. The real problem, is if a large gang snuck up on your friends, and all of a sudden, voted you out. Sort of a DDoS... unless maybe you deliberately trusted your friends? Sticky issue.
Hrrrrmm. It's interesting to think about anyways. Let me know what I forgot. n..n
