I'm late to the party, but I noticed something that begs a errata.
In the second edition open play test docs for mesh activities every device has it's very own micro AI defending it. Ok, I gather a simplification to just help things along, it also turns out to be a extra rule with a very bad loophole.
Get some motes, ectoes, or just arrange anything sing from least mission critical to most mission critical. Every firewall but the far end three rules. /Only/ three rules.
1. Only accepted incoming connections from the next up the line.
2. Only forward traffic to the next device down the line.
3. Discard all other traffic.
By this point you have to get by the entire party's line of device 4-20 (without artificially extending it), in order, without raising a single alarm. Doable, but difficult in your getting into odds that are 1% or lower.
Every 6seconds randomize the order in preset and compartmentalized ways. A compromised device might know the next device in the chain, but after that it has to guess. Every reset every device knows exactly where an intruder is. A device either violates one of the three rules when connecting to it out of order, or traffic to or from the device is sniffed that violates one of the three rules (Because the hacker doesn't know the new chain order).
Compromised devices in the chain can be instantly flagged, cut out, shutdown, restored from secure backups made before the mission starts, and put back into service. To compromise a network a intruder must now hack every device in a chain 4-20, they must do it every time, without fail, the first time, in under 6seconds.
Edit 2:I forgot cycling devices out of the chain to reset them (or pass updated chain orders along) even if not compromised to clear any rootkits or backdoor that slipped in.
Edit: Because of so many eyes under direct player control -that you can perfectly predict- hacking becomes statically impossible.
Welcome! These forums will be deactivated by the end of this year. The conversation continues in a new morph over on Discord! Please join us there for a more active conversation and the occasional opportunity to ask developers questions directly! Go to the PS+ Discord Server.
Nasty loophole 2e mesh rules
Mon, 2018-10-15 02:36
#1
Nasty loophole 2e mesh rules
Mon, 2018-10-15 04:20
#2
Yeah that seems a really nice
Yeah that seems a really nice feature. I command your ingenuity.
To poke a few holes in this scheme. Using this tactic means every device has to route ALL the traffic through it. Peripherals that are meant to be slaved probably have just enough throughput to fullfill their functions. I don't know how many devices you meant but surely you didn't mean your smartgun?
So you are basically choking the traffic. Which is a good defense measure but also limits you.
Now the other thing is how does the chain react to losing a device? I mean how the information is transferred that the device is now a no go? Because when something goes wrong you have a hole in the chain despite it being arranged in any way, reshuffling doesn't fix that.
Also the hacker could attack the devices the entry of he succeeded enough times he would be able to guess or just obtain the full chain structure.
Then there is a problem that it hinders you almost as much as the hacker. Lose contact with one person, you are cut off.
EDIT:
To reconfigure the chain without wrecking everything you would have wait until the comprised device is at the end of the chain and reconfigure it all at once.
EDIT2:
Losing more devices than one at the same time makes this useless.
EDIT 3:
So it makes it easier for the enemy to knock your EW capabilities out while at the same time it makes them weaker.
To restart the chain you would have to drop it and reupload new schedule all at once. But wait the devices only accept the up and down the line info. So Central node can not that.
But let's program additional 1 second wait time for the resync command from central node. Now a hacker can spoof it and destroy your construction.
EDIT:
It is nice in theory but would probably need much b more work to be remotely practical. You would probably be better off just turning off the mesh if under hostile infoattack
—
Exurgents wanna eat your ass and you are low on ammo? Register to mobile gear catalogue at [url=http://eldrich.host]eldrich.host.mesh[/url]! ORDER NOW! FOR FREE PLASMA MINIMISSILE PACK! *explosive delivery options included
Mon, 2018-10-15 11:13
#3
Ok, example of the above idea
Ok, example of the above idea, just tweaked a little. We have a start point, three middle links, and a end point. With a total of 20 devices active or inactive. You don't have to tell any part of the plan all at once unless your the protected end point.
We'll start with a muse in a mesh as 'Root'. Slot 1, 2, and 3 as motes in the middle. 'Ecto' as a end point that actually does all the talking to the mesh at large. Slots 1,2,3 are currently occupied by motes 3,17, and 9. (Turns out only 9 and 17 matter.). There are 20 motes in all. To access the muse you have to go from 'Ecto', to Slots 1 to 2 to 3, and last to he Muse. If you go out of order your instantly flagged and ejected. If you spoof a ID to get ahead of things the current user of that ID broadcasts a 'That's not me!', and your ejected.
Every device has every a 'in case of hacker' switch to plan number X. Thanks to trans humanity's processing power and storage that could include every permutation of every device in any order setup as a contingency.
Turn 1:
Your a hacker trying to get into the network. You've quietly slipped into 'Ecto', back doored it, and know mote 3 is about to take 'Slot 1'. It just turned on it's wireless, 'Muse' just gave a one way broadcast to 'Ecto' that mote 3 is the next in line, and Mote 9 is already handing off traffic to it.
You try to to get ahead of the ballroom dance and start hacking mote 3.
Turn 2:
Motes are not very sophisticated, You get in to mote 3.
Mote 9 goes offline, and all it's drives are being purged. In a turn it will do a firmware reboot, be primed for it's next use by 'Muse', and stay tirelessly inactive until it's turn.
Turn 3:
Mote 9 has already cycled out of Slot 2. You already know from traffic Mote 7 is currently in 'Slot 2', still have through Mote 3 to get to 7. You access mote 7 from Mote 3.
Turn 4:
Mote 3 cycles out of Slot 1 and your disconnected. You know what motes occupy what slot, but don't have enough time to go dance get through the ballroom of dancing motes -in the correct in order- before it's all changed.
Turn 10+:
Just for good measure 'Ecto' hands off it's traffic to a waiting and previously inactive replacement to be purged and put back in line with other ectos.
Even if you can predict 'Muse's pattern the motes don't come online until just before they're used, and 'Muse' methodically and securely purges and resets every mote it takes off line so there are no lingering backdoors. You can't wait for a compromised mote to cycle into 'Slot 3', and you can't compromise a mote to tell you the order ahead. Even if you could get a rootkit in one of the 14 inactive motes waiting for their turn to dance to turn on it's wireless and spill the beans ... the other 19 motes would hear it (Edit: In that it transmitted anything at all), and change the order. (Edit2: Or if enough nodes are compromised the entire network just shuts down, is purged, and comes back online with a clean slate. Edit3: It can just length the chain or bring even more motes online. You still don't reach 'Muse'.)
'Muse' would then just go for a harder purge of your root-kitted mote or do proactive things as it knows there's a active hacker now.
In the end there are too many by the rules free eyes that you 'know' follow fixed rules, and can be cycled out ad infinitum to prevent any foot holds. It very easy to spot a interloper. If your a hyper corp you could have thousands of motes in line waiting to take their turn on preset timers and patterns that never repeat. Any mote is recycled after use, and new ones just printed from scratch and dropped in place.
In metaphors it's a ballroom dance. With dancers that dance in new ways every few seconds only they know about ahead of time. With so many dancers you can't permanently subvert or predict far enough ahead. You don't even know who is going to dance or quietly stand by a side wall until they're ready dancing to suddenly start dancing again. By the time you can subvert them or predict the current pattern, the dance master you want to get to has whispered in the ears of the dances waiting on the sideline you can not eavesdrop on to change the dance in radical ways. Predicted patterns are changed, and subversion brutally undone. You can't get to the far side without all eyes in the ballroom knowing you did a ballerina's twirl when you should have bowed half way across the ballroom.
Mon, 2018-10-15 12:18
#4
TLDR? (My god what walls of
TLDR? (My god what walls of text!) Too many free security AIs easy to access...
Here's a practical application:
Router Cute: By tongue and cheek sometimes called an A-Mazing cube. The cube is a 1ft. black tube with three fiber optic connections. The first and second are data ports, and the third the only access to a air gaped ALI. The cube contains a slurry feedstock, protean nanoswarm, and disassembler nanoswarm. Both swarms are slaved to the ALI. At any given moment the ALI is assembling or disassembling motes. With only twenty motes functioning at a given them in a grid at anytime. Each mote is arranged in a grid pattern and has twelve connections, only two of which connect to other motes.
Only the Airgaped ALI know which of it's many internal slots contain motes or usable links to other motes. It only provides that information through it's dedicated link. The ALI never provides information about what motes are being internally disassembled, actively assembled, or in a unconnected just assembled standby.
The first trick of the cube is to pass information through the cube a user has to tag packets with instructions for how each mote is to connect to the next mote to or forward returning MeshID information to. The motes have no other form of routing. Errors in these instruction transmit the data to dead ends. Any data it receives without without routing information or expected returning MeshID of a active connection is discarded out of hand. Only the airgapped ALI may provide the correct path through the cube at any given time.
The second trick of the cube is attackers may attempt to hack through way through each mote in the cube to get at a user, but have a limited window to do so. They don't require routing instructions as the motes will forward already opened connections correctly. The cube's ALI is always deconstructing and reconstructing paths through the cube. It will provide routing information only for the current path and a path about to come online. A hacker has only until a user is provided with and switches over to a new path through the cube. After that the current path is either disassembled or in the process of being dissembled, and any subverted motes inside the cube simply transmit their data to dead ends or trap doors that go nowhere but to other trap doors. A hacker must begin their hacking attempt with first mote in the new chain again. (Edit: Assuming they even realize their current trace through the cube isn't active anymore.)
A single cube may only cycle paths once every minuet with multiple unique paths under disassembly or various stages of construction at any time. However more then one cube may be chained together so at at least one cube in the chain is reset in cycles as fast as once a turn.
Mon, 2018-10-15 15:18
#5
Hmm. I didn't consider backup
Hmm. I didn't consider backup motes.
I will have to think it through.
...
At this point I can only change "the angle of attack" and ask why an exploit that works on 1 firewall in the chain wouldn't instantly bypass all the others?
You would have to load each mote with its own customized firewall otherwise one exploit allows to compromise the whole chain.
Also it would be possible to attack only the end user firewall, by hiding the virus in an legitimately send file. Where they would get a single Infosec test to recognise and disable not enable the virus.
—
Exurgents wanna eat your ass and you are low on ammo? Register to mobile gear catalogue at [url=http://eldrich.host]eldrich.host.mesh[/url]! ORDER NOW! FOR FREE PLASMA MINIMISSILE PACK! *explosive delivery options included
Mon, 2018-10-15 20:21
#6
Not sure it's as big a
Not sure it's as big a loophole as you might think. Hacking is primarily about gaining access to a system, and potentially doing things with the system that your current credentials do not allow. The important correlation is that if you have what the system views as proper authentication, there is no hacking test required. Furthermore, if you're doing something your current login credentials require, there is also no test required.
So, all someone needs to do is hack one member's device, and send communications as that device to the other ones to access what they need. The only way you COULD close this loophole would require the participants in the chain themselves to make a hacking test for every link between them and the outside world every time they wished to access the mesh at all. At which point you may as well just turn your mesh off.
Sat, 2018-10-20 18:43
#7
Yep.... what the Urthdigger
Yep.... what the Urthdigger said.
At this point you can adapt the analogy of a key. You designed a lock very hard to bypass. The key is a routing sequence and authentication codes. When you can't break the lock you may as well steal the keys.
It could be a great system if it used quantum exchange of routing information to avoid some issues.
What's more there is a paragraph in lore section of the book where it states why you do not copy or fork all great Infosec experts or use AIs everywhere. It was said that they are vulnerable to exploits. And if it works on 1 it works on all of them. Your cheap AI would be the same. 1 exploit can work on all the copies.
EDIT: so mechanically your strategy is sound. I would say RAW it is impenetrable. But GM fiat should shoot it down pretty quickly.
—
Exurgents wanna eat your ass and you are low on ammo? Register to mobile gear catalogue at [url=http://eldrich.host]eldrich.host.mesh[/url]! ORDER NOW! FOR FREE PLASMA MINIMISSILE PACK! *explosive delivery options included
Sat, 2018-10-20 20:43
#8
Yeah. Alternatively? Sniffing
Yeah. Alternatively? Sniffing and spoofing would bypass this quite easily. One would just need to sniff the packets being sent to a legitimate server to get that specialized routing information for the current order, then spoof itself as the MeshID belonging to the server to skate on by all these complicated hoops. It's a necessary evil, as anything that COULD stop it would also slow down the network sufficiently to cripple the advantages the mesh gives.
Once it bypasses all the routing shenanigans and gets to the device, not ALL hope is lost for the defender though: The ALI can still detect that the program is doing something suspicious or that a logged-in user is doing something their credentials should not allow and attempt to stop that. But at this point we're back in the realm of typical hacking tests.
Mon, 2018-10-22 04:05
#9
Sniffing and spoofing won't
Sniffing and spoofing won't work in a chain of devices who are "cabled"... and we are talking about personal mesh.
The only "sinffable" part would be from the exit node to the external mesh, all internal would be an intranet analogous.
Ah, the times when we used the rules of Netrunning to hack microsystems in CP2020... those were the days (Rach Bartmoss' Guide to the 'Net, I think).
Mon, 2018-10-22 20:29
#10
Well, two things. First, what
Well, two things. First, what exactly is stopping someone from sniffing communications between two of the devices? Unless we're getting into QE comms shenanigans or having all the devices literally cabled together, you're sending out radio waves that the other devices are picking up on, that's totally sniffable.
Secondly, packets between the exit node and the external mesh should be all you need. If any of the devices access the external mesh, the reply back from whatever they're communicating with has to send a reply SOMEHOW. The method by which it sends a reply can be used as a potential vector. Once the hacker has access to any given node that way, if they can devise a method to see where the connected points in the chain are (Sniffing between the two, monitoring traffic on the device, etc.), they could then move between points or wait until the node they're after becomes the next link in the chain.
Tue, 2018-10-23 06:08
#11
Urthdigger wrote:Well, two
If we are talking about a PAN composed of devices phisically "carried" by the body (mesh inserts, ectos, drawn weapons, Ghostrider modules...) then we are, indeed, talking about cabled devices, with a single point of interaction with the external 'net, which is the one sending the wireless signals.
This demands to have some sort of interface port near the weapons (for example, a port that slots in the grip of the gun, or some extremely low-range wireless signal able to reach barely 2cm or so, and that gets turned on only by internal demand. There is an implant that turns the skin into I/O ports of universal capability, however, and nothing prevents to have a patch of such material in a precise point of the skin).
This does not prevent the "shuffling" of the line the OP mentions, if it's desired, since we are are not talking about a mechanical operator but a digital one using digital addresses like IPs.
Of course, the only way to be sure you are not hackable is to stay in some sort of Autist mode that prevents any and all stimuli from reaching the ego (because, well, Basilisk Hacks and Exurgent viruses affecting bio and synthmorphs).
The idea of this exercise is, simply, to impose as many rolls as possible to the prospective hacker as possible without impairing regular operations.
Personally, my "debunk" to this kind of strategies is simple: if you do it, EVERYBODY and EVERY SYSTEM will do so, thus rendering the Hacking rules a useless waste of data in the book. A certain level of abstraction needs to be agreed upon, and that level is the one described in the rulebook: you can be harder to hack if you improve your Infosec, your Muse's Infosec, and spend resources into having better hardware & software.
Getting creative is allowed, but will give a bonus to hacking/antihacking attempts (from -30 to +30 more often than not, depending on how the GM wants to implement the stuff) for a limited amount of time until the idea is so widespread everybody uses it and knows how to go around it.
That way, everybody can be creative, not just those with some knowledge (or a lot) about computer security.
Wed, 2018-10-24 22:56
#12
My point wasn't that turning
My point wasn't that turning off the mesh entirely is the only way to be hack-proof (Although that is true.) Rather, my point was that due to the way the mesh works, this sort of complicated routing does jack diddly for someone masquerading as a legitimate connection.
For any of the devices within the network to communicate with the outside world, stuff on the outside needs to be able to route information to the node. By appearing to be a normal reply, the hacker's transmission would get routed to the device without interference. I think folks are under the impression that hacking attempts are in some way different than normal net traffic, that they have to force their way into every step along the way to their target. In truth, hacking attempts are less like trying to tunnel through rock and more like a typical infiltration attempt: You try your best to look like someone that's supposed to be there and hope nobody is looking too closely when you try something that's not in line with your cover.
Someone did bring up the idea of having the packets include routing information for how to send the data back along the correct path... but this assumes the target device has any idea what to do with this information. Nobody normal ever requires their data to return along a very specific pre-defined path (Unless this type of security were normal, in which case it could be assumed infosec training covers this), which means any outside device you connect to would likely regard that information as junk. I mean, you could still use that kind of information if you specifically programmed the end device and every device along the chain to use that information correctly, so it could be used for secure communication between two known points, but that's called a VPN and already covered within the book (Gives the hacker a -30 to their Infosec test). Heck, this whole security system the thread is about is simply a more complicated version of the Tiered Systems bit covered in the book, though to actually act like this anything within the chain would need to have no communication whatsoever with the outside mesh, essentially rendering them useless.
So far, it seems the most this gives to security is flushing all users every 6 seconds, which does help security but can make communication annoying. Oh, but what if you do indeed insist that every node along the chain scrutinize all data coming through for anything suspicious regardless of what device it goes to? Well, in this case you're severely throttling the speed of your network, requiring an ALI to analyze every packet before sending it on to the next node.
And even after all that... you're not forcing the hacker to make a ton of rolls. This clearly falls under the Teamwork bonus, which benefits from a maximum of 3 assistants for a +30 to their Infosec roll. There's still no guarantee that the hacker won't beat them on an opposed test or get a critical, or that they won't fumble.