Half a cool idea..., Did you ever... Options

[crizh]

I had this epiphany of a really cool way to keep a teams network secure.

I seemed like genius but the more I try to pin down the details the further it slips away from me.

You ever get that?

So I'm hoping you guy's might be able to iron out the kinks or spot what I'm missing.


So the basic idea is this. You slave everyone's comm-link to a master owned by the hacker. Some sort of nexus might be handy. Then you load an Agent onto each of the slave nodes and a master Agent onto the master node. These Agents then create a second subscription between each slave node and the master. The master separates these into two groups, or channels, call them A and B, that each slave node connects through both of.

The intention of the Agents is to make this transparent to the nodes so that the same data travels through both channels but there is a layer of redundancy so that if one channel goes down for some reason the connection is not lost.

Then the Agents start to operate a rotating Spoofing and Encryption system. As soon as each channel is established the Master Agent encrypts it and transmits a new Access ID and Encryption Key to the Slave Agents. Every 12 seconds, on a staggered schedule, the Master Agent breaks the connection to every device on one 'channel' It then spoofs that channel to use the Access ID it already provided the Slave Agents with and waits for them to reconnect. When a channel is dropped the Slave Agents re-connect using the new Access ID and the Master Agent re-encrypts the whole channel with the Key that the Slave Agents already possess. It then transmits a new Access ID and Encryption Key over the newly secure channel and proceeds to do the same thing 6 seconds later with the other channel and so on and so on.

So long as some way to keep this transparent exists, which is where I can't seem to see the wood for the trees, this would result in a network that, once set up, communicated over two encrypted channels that never use the same Encryption Key or the same Master Access ID for more than 6 seconds and never transmit either over a channel that is not freshly encrypted. It takes a minimum of 1 combat round to decrypt a signal so by the time you break the encryption it is already too late and the channel has been closed.

This narrows hacking options down to physically jacking into a Slave Node or Cracking the Master Node.

[Aaron]

A couple of things off the top of my head:

First, how are the slave nodes connecting to the master node? If it's wireless, then they can be hacked without being physically jacked into if the attacker is within Signal range of the slave device (and her own commlink, obviously).

Second, would this be better than clustering?

[crizh]

If it's wireless, then they can be hacked without being physically jacked into

No a Slave Node must be physically hacked or have the masters Access ID spoofed. (Unwired p55)

The second is not possible with this set-up.

Second, would this be better than clustering?

I don't know if clusters can be created wirelessly.

If they can they would be a preferable configuration to this as the cluster could only be hacked by direct attack on the virtual node which would be stronger than any of it's individual components.

[WeaverMount]

You are basically describing frequincy hopping, which is a real technique that is really powerful. You should go look it up ... or just wait for WMS to show up.

[Heath Robinson]

It then transmits a new Access ID and Encryption Key over the newly secure channel and proceeds to do the same thing 6 seconds later with the other channel and so on and so on.

So long as some way to keep this transparent exists, which is where I can't seem to see the wood for the trees, this would result in a network that, once set up, communicated over two encrypted channels that never use the same Encryption Key or the same Master Access ID for more than 6 seconds and never transmit either over a channel that is not freshly encrypted. It takes a minimum of 1 combat round to decrypt a signal so by the time you break the encryption it is already too late and the channel has been closed.

Once you crack the first encryption, assuming you've been saving the encrypted forms of the other signals, you can use the key in the first recorded transmission to read the rest of the daisychain in turn and instantly catch up; it doesn't take a decrypt action to read the encrypted form when you have the key. From then on they can listen in on the communications without any trouble.

[crizh]

You are basically describing frequincy hopping, which is a real technique that is really powerful. You should go look it up ... or just wait for WMS to show up.

Is it not multi-plexing?

I am, indeed, hoping that WMS will show up and set me straight.

[crizh]

assuming you've been saving the encrypted forms of the other signals

You're not allowed to intercept a signal, in SR4, until you've broken the encryption.

Presumably, if packet headers are encrypted it is impossible to determine which packets form part of which stream, etc, etc, fluff, fluff...

[Aaron]

No a Slave Node must be physically hacked or have the masters Access ID spoofed. (Unwired p55)

Really?

*readreadread*

Awesome. Last I'd heard it was the way I just described it. I'm glad it got changed back before the final version.

[Heath Robinson]

You're not allowed to intercept a signal, in SR4, until you've broken the encryption.

Presumably, if packet headers are encrypted it is impossible to determine which packets form part of which stream, etc, etc, fluff, fluff...

If the packet headers are encrypted it is impossible to tell packet from noise, even by the people it's intended to reach. The packets have to be distinguishable from noise for networking to work, and noise is everywhere.

Damnit, the rule is retarded and should read "you'll need to decrypt the recorded copy of the signal" to make sense at all. Then, again, in a ruleset where some random hacker decrypting your signal reveals it to everyone in the area (it's not encrypted anymore, so anyone can listen in) is not going to make sense to someone who knows what they're talking about in the area, and positively revels in it.

[JoelHalpern]

If the packet headers are encrypted it is impossible to tell packet from noise, even by the people it's intended to reach. The packets have to be distinguishable from noise for networking to work, and noise is everywhere.

Damnit, the rule is retarded and should read "you'll need to decrypt the recorded copy of the signal" to make sense at all. Then, again, in a ruleset where some random hacker decrypting your signal reveals it to everyone in the area (it's not encrypted anymore, so anyone can listen in) is not going to make sense to someone who knows what they're talking about in the area, and positively revels in it.

What you can do with recorded transactions depends very much on what you assume about crypto.
In order to make things work, SR has to assume that much of crypto is broken by 2070.
Using todays tech, for example, I can establish communication with someone and exchange material to establish secret key such that even if you read the exchange, you can not extract the key. (This is known formally as perfect forward secrecy.) You can indeed rinse and repeat (and good crypto policy calls for doing so. The only question is how often to change the keys.) So you can set it up so that the two parties exchange a key, use the key to exchange a frequency, and then jump to a jump to a new frequency. As long as the key break time is longer than the cycle time for the operation, current traffic can never be read.
But all of that is current.
Whether it works or not in SR, I have no idea.

I tend to assume that to the degree they work techniques like spread spectrum (really fancy frequency hoping) and dynamic shared keys with "strong" forward secrecy are part of what underlies the abstract mechanics of the rules. It would seem to be a bad idea for the players and GM to try to be amateur cryptographers and try to craft more or less complex modifications of the basic pairwise crypto mechanics that the rules declare. (Finding clever ways to use clustering or master/slave seems a sensible effort to understand and use the rules. Just stay away from the mathematics.)

Joel

[WeaverMount]

It would seem to be a bad idea for the players and GM to try to be amateur cryptographers and try to craft more or less complex modifications of the basic pairwise crypto mechanics that the rules declare. (Finding clever ways to use clustering or master/slave seems a sensible effort to understand and use the rules. Just stay away from the mathematics.)

Joel

My thought's exactly. I don't care if you learn Tagalog set up everything on your pan to use that and only that from the GUI to the BIOS, that doesn't make your drones unhackable, because exploit says it creates user accounts, and command says it issues orders. Same thing with crypto.

[Zaranthan]

I tend to assume that to the degree they work techniques like spread spectrum (really fancy frequency hoping) and dynamic shared keys with "strong" forward secrecy are part of what underlies the abstract mechanics of the rules. It would seem to be a bad idea for the players and GM to try to be amateur cryptographers and try to craft more or less complex modifications of the basic pairwise crypto mechanics that the rules declare. (Finding clever ways to use clustering or master/slave seems a sensible effort to understand and use the rules. Just stay away from the mathematics.)

Joel

This strikes me as the most elegant way of handling things. Just assume that Encrypt does this automatically, and the rating comparisons and skill tests are the result of the broadcaster and hacker racing to get ahead of one another. If the hacker wins, he gets your key before you change frequencies, and then simply follows the next encryption cue. If the hacker fails, then you've changed keys before the hacker catches you. If the hacker scores insufficient hits, he's caught a part of your encryption pattern, but not enough to get the data.

I don't treat a decrypted stream as suddenly being an open transmission. The users would notice and I'm not seeing a rule that suggests it should be that way. It's still encrypted, but the hacker is now treated as a legitimate receiver, and can understand the transmission. He can relay it to anyone he wants, but if somebody else wants to sniff in, they have to do their own decryption.

[Heath Robinson]

In order to make things work, SR has to assume that much of crypto is broken by 2070.

Under RAW, if somebody, somewhere in the world, manages to crack your WEP key everyone instantaneously gets access to your wireless connection until someone takes an action to re-encrypt it. No amount of broken crypto makes that kind of ftl universal information dissemination possible. Some of the Matrix and Computing rules in SR destroy verisimilitude by preventing you from doing things that are possible in the world they seem to be trying to simulate. The original poster, crizh, has designed a system that manipulates this fact to become invulnerable.


I'll work entirely within RAW to criticise his algorithm, though.

Transferring a file or information doesn't finish until the end of the combat turn, so the actions necessary to reconnect the nodes and encrypt all the connections must occur from the start of a combat turn. First, the master commlink has to Spoof its AccessID, the rules don't state the kind of action this requires so it's 1 simple action for our purposes. Next the other commlinks slave themselves to the new AccessID, 1 more simple action (again, no rules provided on what kind of action this is). Now comes the encryption, 1 simple action for every slaved device, rules in wired state 1 simple on each end for each connection. Then we spend a number of simples equal to the number of devices to initiate the transfer of the next key and AccessID. It's possible for an agent to have cracked one of the connections and then sniffed the transfer and be ready to read all future changes instantly, so long as there a number of other devices.

In IP 1, the master commlink spoofs its new ID. Somewhere before IP 3 all the other devices are slaved. IP 3, the master agent encrypts two connections (it is not stated that one of the two simple actions in an IP occurs first, hence they occur simultaneously and so any transmitted information would be sent through an unencrypted connection), the attacker has waited on the encryption and initiates any number of decrypt attempts on both of these connections. In the second combat turn, the master commlink can begin the transmission of the file. In IP 3 of the second combat turn, the decryption of the connections either succeeds or fails, any number of other attackers have been waiting for this and sniff the file before the end of the turn (it is not stated that there are special effects for begginning a sniffing attempt part way through the transfer of a file or information). Next cycle through, the attackers instantly sniff the connection as soon as it is established and grab the next file as well as everything else.

RAW, I can hack this system. Well, certain interpretations of RAW, since it doesn't explicitly say that I'm allowed to and it doesn't forbid it either.

[crizh]

Now comes the encryption, 1 simple action for every slaved device, rules in wired state 1 simple on each end for each connection.

That's a reasonable assumption but not necessarily what the text says. I'm making the not 'unreasonable' assumption that one can encrypt multiple subscriptions with the same simple action so long as you use the same key.

So...

[ Spoiler ]

IP1 - Master: Drop all Subscriptions in 'Channel A.' (Simple), Spoof Access ID system presents to 'Channel A.' (Simple)

IP1 - Slaves: Log In to Master on 'Channel A.' (Complex)

IP2 - Master: Encrypt 'Channel A.' (Simple), Delay

IP2 - Slaves: Delay to End of Combat Round, Encrypt 'Channel A.' (Simple)

IP3(End of Combat Round) - Master: Transfer Data (Next set of Encryption Keys and Master Access ID for 'Channel A.') over 'Channel A.' -Simple

By waiting for the end of each six second window to complete re-encrypting the channel no observer ever gets more than six seconds to attempt to decrypt it. It may be possible to succeed but the most you will ever decrypt will be a whole bunch of drop-connection commands.

Alternatively, assuming discrete subscription encryption.

[ Spoiler ]

IP3(End of Combat Round) - Slaves: Drop all Subscriptions in 'Channel A.' (Simple)

IP3(End of Combat Round) - Master: Spoof Access ID system presents to 'Channel A.' (Simple)

IP1 - Slaves: Log In to Master on 'Channel A.' (Complex)

IP1 - Master: Encrypt 'Subscription 1.' (Simple), Encrypt 'Subscription 2.' (Simple)

IP2 - Master: Encrypt 'Subscription 3.' (Simple), Encrypt 'Subscription 4.' (Simple)

IP2 - Slaves (1-4): Encrypt 'Channel A.' (Simple), Delay to End of Combat Round

IP3 - Master: Transfer Data (Next set of Encryption Keys and Master Access ID for 'Channel A.') over 'Channel A.' -Simple, Delay to End of Combat Round

IP3(End of Combat Round) - Slaves: Drop all Subscriptions in 'Channel B.' (Simple)

IP3(End of Combat Round) - Master: Spoof Access ID system presents to 'Channel B.' (Simple)

or, further assuming key transfer by text message.

[ Spoiler ]

P3(End of Combat Round) - Slaves: Drop all Subscriptions in 'Channel A.' (Simple)

IP3(End of Combat Round) - Master: Text Message(Next set of Encryption Keys and Master Access ID for 'Channel B.') over 'Channel B.' -Free, Spoof Access ID system presents to 'Channel A.' (Simple)

IP1 - Slaves: Log In to Master on 'Channel A.' (Complex)

IP1 - Master: Encrypt 'Subscription 1.' (Simple), Encrypt 'Subscription 2.' (Simple)

IP2 - Master: Encrypt 'Subscription 3.' (Simple), Encrypt 'Subscription 4.' (Simple)

IP2 - Slaves (1-4): Encrypt 'Channel A.' (Simple), Delay to End of Combat Round

IP3 - Master: Encrypt 'Subscription 5.' (Simple), Delay to End of Combat Round

IP3 - Slave (5): Encrypt 'Channel A.' (Simple), Delay to End of Combat Round

IP3(End of Combat Round) - Slaves: Drop all Subscriptions in 'Channel B.' (Simple)

IP3(End of Combat Round) - Master: Text Message(Next set of Encryption Keys and Master Access ID for 'Channel A.') over 'Channel A.' -Free, Spoof Access ID system presents to 'Channel B.' (Simple)

Those models allow four or five slave nodes to be subscribed. If you have more than 4 or 5 slave nodes that just means you have to run an additional Agent on the Master Node and create 'C' and 'D' Channels.

Regardless, in all instances, new keys and Access ID's are transferred a full six seconds before even 2070's miracle decrypt algorithms could possibly penetrate the encryption.

The point being that the RAW is [insert Frank's rude comment of the day] in two regards.

Firstly that traffic can not be intercepted without first breaking encryption.

Secondly that Decryption takes a minimum of one combat round regardless of how many hits you get.

And thirdly that Encryption is so easily penetrated given more than about ten seconds.

Yes, I know, that's three, so sue me.

Actually the real point was that I wanted to design a way of forcing Hackers to come into a teams Coms through the Hackers comm-link where one could reasonably assume that the Hacker would have a fighting chance of earning his keep.

Oh and that I hadn't quite got certain elements conceptually correct and I was looking for some help.......

[Blade]

Personally I don't want my players to start playing cryptographic games... We'll end up reinventing modern cryptography and I don't think it'd be very interesting in a gaming context. I prefer to consider this:
1) Encryption rules as written are good for the game.
2) People aren't stupid and if there was such a thing as a ultimate solution to encryption, it'd have been described.

Which lead me to a simple explanation: The encryption program already covers the use of spread-spectrum, symmetric key, multiple encryption layers, perfect forward secrecy and so on. The higher the rating, the more of these techniques it uses.

[Heath Robinson]

That's a reasonable assumption but not necessarily what the text says. I'm making the not 'unreasonable' assumption that one can encrypt multiple subscriptions with the same simple action so long as you use the same key.

Signals Encryption
A connection between two nodes can be encrypted to help protect it from eavesdropping... Initiating signals encryption requires a Simple Action by each node, but no further action...

The rules are phrased in terms of a connection between two nodes, and nothing else. It takes a simple action for each slaved device.

Still, the text-messaged key and ID breaks my attack if you modify your algorithm to transmit as soon as the encryption is applied to the signal.

[Ryu]

I do not think it is kosher to spoof only part of your own matrix ID. You can either spoof yours (for all nodes, you only have one), or spoof selected commands to other devices. Consequentially, spoofing your matrix ID would break both channels.

Now for the next variant, you´ll need one hidden, unslaved router per PAN. Activate device (botnet command), establish connection, encrypt, transfer new encryption code for the whole network, disable device (botnet command). Try to even find the data stream before it is over...


If you want protection from the teams hacker, you´ll build your net differently. All PANs are build by slaving the individual devices to a central comlink, preferably over skinlink. Your hacker subscribes to a botnet. The botnet analyses the PANs central nodes (each hosts an agent) and has an intruder alert status. Once there is an alert, the hacker can connect to the attacked PAN, take up a command subscription to the agent, and attack.

If you build your comlinks with optimisation: Analyse and a non-standard wireless link, you are going somewhere. Add a linked passkey system, and noticing an intruder (lack of passkey) requires merely a matrix perception action.

[Carny]

As I've read this thread, one thing that has occurred to me is that if this sort of thing is allowed, the connotations are pretty grim for any hacker, anywhere.

Every corp who wanted to keep any network even moderately secure would just set up something like this, and then have ten spiders sitting on the master node, to fall upon and crush any attempt at hacking. On a more secure network, they'd do the same thing, but it would all be hardwired, with wireless access to the outside world cut off, and the main node sitting in a room guarded by ten layers of physical and well-armed security, all serenely immune to any hacking attempts, because they couldn't be hacked unless somebody got past all of them.

[Cheops]

Unwired 55, Slaving

Hackers have three options when faced with a slaved node. First, they can hack in directly...which requires a physical (wired) connection to the device. Second, they can hack the master node....Third, they can spoof the access ID of the master node and then spoof commands to the slave

(Emphasis mine)

Unwired 55, Clustering: Nowhere does it say that you need to hardwire the connection and in fact the test is just a Computer+Logic (2) test. This implies to me that they can be clustered wirelessly.

Unwired 66, Decrypting

...but when a subscription or node is decrypted by a user, it remains decrypted only for that user. However, the encryption may be reinstated under certain circumstances:
Signals encryption may be restored by closing the subscription (a Log Off action), re-establishing the subscription (a Log On action), and then re-encrypting the subscription (a simple action from each side of the link).

(emphasis added to show this is what applies to sigs)

You can in fact just cluster your team's links together for better security.

With the set up you've come up with a hacker just needs to decrypt once and he is capable of intercepting your comm. Your set up does mean that he can only take a single complex action every 2 passes but he'd still be able to spoof commands to your teammates. In order to restore your encryption you would have to spend 1 complex and 3 simple actions per commlink. As far as I know agents wouldn't be able to do this for you.

Quick question: Are you trying to come up with a security set up for day-to-day use or are you just looking for protection during combat? I need to think about solutions some more and it will help (sorry if I seem negative right now)

[crizh]

I tend to agree with those that posted above that said that this sort of mechanic should fall below the layer of game system abstraction. In reality this ought to be handled with dynamic encryption.

That, however, has an unfortunate and ridiculous restriction that requires the defender to be aware of the encryption attempt which is IRL not really possible nor in any way necessary.

[edit]
Looking at the mechanic of dynamic encryption it appears to be a bit retarded. It ought to make the whole decryption task into an extended opposed test, a bit like hacking on the fly.
[/edit]

The way I would make this work in game ATM would be to use a similar system of Agents but with only single subscriptions. They could watch for decryption attempts, perform dynamic encryption on any subscription that is being decrypted and periodically re-spoof the master node's Access ID and re-slave the slave nodes.

This ought to be able to hold off a casual encryption attempt indefinitely.