{%hackmd hackmd-dark-theme %} # Networking and Hacking ## Abstract This document introduces a design for networking, comms, and hacking gameplay in Space Station 14. At a high level, the idea is to combine comms, devicenet, and other technological communication into a single system of common mechanics, with the goal of exposing things built on it to player interaction. If successful, this would open a new layer of gameplay rife with possibilities and new modes of conflict. ## Design Goals Here are some guiding bullet points that influenced the design: * The networking system must be simple to integrate with other game systems. * It should act as a new layer of gameplay: a playground for the greytide, an attack vector for antags, and a repair/defense challenge for whomever administers it * High ingame discoverability and high potential for low-stakes experimentation and tomfoolery * We want to enable some cool scenes and stories to arise organically: * Splicing into a cable deep in maint to spy on some important traffic * Tracking down strange activity on the network only to discover the AI is malfunctioning I'm also specifically trying to dodge pitfalls related SS13 mechanics have fallen into: * Low-impact nerdbait in a corner * Binary outcomes (think TComms sabotage) * An unjustified focus on evoking real life computing and networking systems to the detriment of accessibility and fluid gameplay ## The Network :::info **Note:** Initially, I determined that a new cable type would be required, but upon consideration I've managed to eliminate it from the design completely. ::: This section details how devices determine basic connectivity to each other. Devices primarily communicate over a backbone formed by the same wires that carry power, with wireless connectivity being handled by access points attached to this network. ### Device IDs Every device is associated with a globally unique identifier. These Device IDs are used primarily used to indicate the origin and destination of communications. By default, this identifier is simply randomized. If a device has an auth token (see **Authentication** below), then the identifier of auth chip (itself globally unique) is used as the device ID. Since auth tokens are *not* randomized, this allows devices to reliably locate each other. ### Segments The network is composed of a series of interconnected **segments**. A segment is a shared medium with a set of a directly connected devices. Every device on a segment is reachable by every other device on a segment. In addition, every communication sent or received by any device on the segment is visible to all devices on that segment. For wired networks, a segment corresponds to a group of connected wires of a single type (and thus to the current node networks used to model power). For wireless networks, a segment corresponds to the group of devices connected to a given access point. Because messages are visible to everyone connected to the same segment, splitting the network into segments prevents everyone from seeing eveything and means that players cannot simply sit in a room spying on the entire station. ### Routing Some devices connect to multiple network segments simultaneously and may act as relays between segments. Most prominent among these devices are substations, APCs, and access points. Through this mechanism, devices can communicate from one side of the station to the other. Routing is automatic. Communications pathfind through the network and pass through a sequence of segments to reach their destination. Such messages are potentially visible to every device on every segment they pass through, though most devices will not be listening to anything not destined for them. Devices control their participation in routing only by toggling whether they relay communications or not and by optionally specifying filter conditions for relayed packets to the network system. ### Packets and Subscriptions Devices communicate across the network in one of two ways. **Packets** are individual structured messages that players can potentially view, create, and edit. Because they are more interactable, they are preferred where possible. A few examples of things potentially modelled with packets include light switches, tcomms, and door access checks. **Subscriptions** are ongoing connections between two devices with meaning and contents not modelled in the networking system. They are designed to cover use cases packets cannot. For instance, players can view a camera over the network, but it's very difficult to imagine how one would represent that interaction with packets. A subscription, once established, remains established until either loss of connectivity or termination by either device. Other game systems can check to see if a subscription exists between two devices or trigger off connection and disconnection events. Some examples of things potentially modelled with subscriptions include remote machine UI usage and the aforementioned viewing of surveilance cameras. Devices can see the source, destination, and type of any subscriptions that pass through their segment as well as the source, destination, and contents of any packets that pass through. ## Security This sections details the ingame security model of the network - how one can control which devices are allowed to do what and which messages are allowed to go where. ### Authentication Authentication is heavily abstracted and handled by **Auth Tokens**. Auth tokens are globally unique identity tokens that may optionally be attached to a device. These tokens are used to authenticate sent messages by signing them with the auth token. Recipients can then read this signature to determine which token originated the message. Without an auth token, a device may only send unauthenticated messages (at least normally - see **Hacking** below), though may still read the signatures on messages it receives. Auth tokens could potentially be hardware or software: this design is agnostic on that point. However, ID cards are an obvious existing example of something that would be an auth token. ### Authorization Authorization is the process of determining whether someone can do something given that it has been established who they are. Mechanics for authorization already exist, so won't be elaborated here. For the most part, this is not directly part of the proposed system and instead handled inside devices that integrate with it. ### Accounting Most devices should keep a timestamped log. The goal of this is to generate a datatrail that can be used both for investigative purposes and for spying as well as enhancing the discoverability of networking mechanics and aiding ingame troubleshooting. The contents of the log will differ based on the kind of device. For network relays it might reasonably contain records of relayed subscriptions, changes in configuration, and detected suspicious activity (see **Hacking** for what would make something "suspicious"). ### Encryption Encryption has two different functions: obscuring data that passes over "public" segments and controlling access to segments. Accordingly, encryption may be applied to packets/subscriptions or to segments as a whole. Both cases are detailed below. **Encryption keys** provide the ability to encrypt and decrypt communications, and attach to devices in a manner similar to auth tokens. Unlike auth tokens they are not unique: multiple identical keys can (and indeed must) exist. #### Packets and Subscriptions Applied to a packet or subscription, encryption prevents access to all but the source and destination to any device not in possession of a corresponding encryption key. #### Segments Applied to a segment, encryption prevents access to that segment by any device not in possesion of a corresponding encryption key. ## Hacking This section details what tools players have to subvert the security model. ### Spoofing **Spoofing** is the process of sending messages that appear to be signed by an auth token that the sending device does not possess. This requires special hardware. A spoofed packet will always be clearly marked as such on the API level, and will additionally contain a value indicating the "strength" of the spoof. Device implementations can use this information to decide whether or not the device detects the packet as spoofed. If it does, the normal behavior would be to reject it and log a message. It's possible for a relay to peform this detection, and so mappers can create situations where it is ideal to hack from inside some part of the network instead of hacking remotely by placing relays with high detection strength: by hacking from a different physical place you'd bypass such relays. Note that devices do not require special hardware to send unauthenticated messages and that some devices will not check for authentication. This opens up the network to interaction by all players while still allowing higher impact activites to be restricted via gear. ### Cracking **Cracking** is the process of accessing messages and segments for which no corresponding encryption key is possessed. Like spoofing, cracking requires special hardware (and also like spoofing, we might reasonably implement multiple cracking chips with different strengths). Cracking cannot be detected. ### RATs (no, not the furry kind) **Remote Access Tools** or **RATs** provide a way to force a device to authorize things it would normally not. I haven't yet fleshed out ideas here except to determine that something like this should exist. Essentially, there would be a way to "infect" devices so that they authorize something they would usually reject. Confirming that a machine is infected would require a manual scan of some kind, though there would be indirect evidence in the form of logs and, obviously, the infected machine doing things it should not. ## Miscellaneous Musings ### General * This document doesn't assume anything about the wireless connectivity model, but a design for it that prevents WiFi from seeping into maintenance has some interesting gameplay implications. * The design is agnostic about whether encryption keys and access tokens are physical or software. In fact, it doesn't actually have anything to say about how software works (or if it even exists as a discrete thing). * Tcomms might be implemented as a simple relay server for each department. Messages would travel from players, to an access point, onto the wired net, to the relay, and finally to the destination players. * If it were possible to stop an APC from relaying power, one could use an LV cable as a data-only bridge between two segments of MV cable. This might be nice if mappers want to add some redundancy to the network. ### AI * These mechanics should enable meaningful conflict between two AIs fighting over the same network, should that be something we'd ever want to explore * Hopefully it's is possible for AI interaction to be 100% mediated through this system - clicking on doors could send packets, vision and remote UI usage could be achieved through subscriptions. * These mechanics enable a lot of minor tomfoolery and are open to any antag. This means that when doors and other devices do weird things, one cannot immediately assume the AI is antag. * At the same time, an AI built on these mechanics would be very reliant on physical agents to maintain network connectivity and control.