Startseite Foren RiftRoamers Dystopia RPG CommunityLab ThinkingNets NAX – Netwechsel

  • Dieses Thema ist leer.
Ansicht von 3 Beiträgen - 1 bis 3 (von insgesamt 3)
  • Autor
    Beiträge
  • #2251
    Fred_Krug
    Mitglied

    Hey.

    Hier habe ich bereits beschrieben, wie ein mögliches LogOn-Verfahren aussieht, wenn ein NetDiver sich mit einem Netzwerk verbindet.

    Verkürzt dargestellt:

    1. Er bereitet die NetDive-Session vor, an dessen Ende er eine APID generiert hat – PreP (Preparation Phase).
    2. Der Avatar wird im Netzwerk bereitgestellt (also hochgeladen, angepasst, ggf. Sicherheitsmaßnahmen getroffen) – Splash (Dive-In, eigentliches LogOn).
    3. Der NetDive wird durchgeführt.

    Üblicherweise verbindet sich ein NetDiver mit einem Netzwerk, um in diesem Handlungen durchzuführen. In einem Raumschiffsystem oder Stationssystem, ggf. einem spezifischen Subsystem (!), wird die Verbindung genutzt, um Informationen zu erhalten oder bestimmte Funktionen der Stationen zu steuern. Im öffentlichen offenen Netz (vgl. www) geht es um Recherchen, Buchungen, „einfache“ Handlungen, Treffen (aka Chat), Programmierungen etc.
    Die Liste ist lang.

    Der professionelle NetDiver wird nicht umhinkommen, gegebenenfalls einen LogOn in Netzwerk A durchzuführen, um aber auf Netzwerk B zuzugreifen. Das kann sich dadurch begründen, dass er keinen direkten körperlichen Zugang zu dem Netzwerk B erhält, oder aber dadurch, dass das Netzwerk B ein „verstecktes“ oder untergeordnetes Netzwerk/ Subsystem darstellt. Auf abstrakter Ebene spielt das keine Rolle.

    Was aber eine, naja, eigentlich mehrere Rollen spielt, das sind die folgenden Fragen:

    a) Was passiert beim Net-Wechsel?
    b) Welche Probleme stellen sich dort automatisch ein?
    c) Wo liegen die Hack-Potentiale für Grey- und Blackheads?

    a) Was passiert beim Net-Wechsel?

    Im Grunde genommen geschieht beim Net-Wechsel – genauer net-access-exchange (NAX) – das gleiche, wie bei einem einfach LogOn Verfahren.
    Denn grundsätzlich stellt die Verbindung des NetDivers mit seinem Cyberdeck / Terminal nichts anderes als ein LAN dar, das sich aber nicht als solches sondern als eigenständige Persönlichkeit im Netz bemerkbar macht.

    Tatsächlich stellt ein anderes Netz oder ein Subsystem auch in gewisser Weise eine eigene Persönlichkeit dar – bedingt durch seine Technologie, seine „Art“ der AI und seine Funktionen. Allerdings sind die Netzwerke durch das Prinzip GlobalNet auch als Netzwerkkomponenten miteinander verlinkt. Ungeachtet ihrer „Persönlichkeiten“ oder Darstellungen als „Avatare“ in einem Meta-Verständnis sind sie integrale Bestandteile eines Gesamtnetzwerkes. Die Zugangspunkte, über die sich User und NetDiver einloggen werden andersartig, nämlich als externe Zugänge, spezifiziert. Hier „weiß“ das GlobalNet bzw. das jeweilige Netzwerk, dass ein Zugang von außen erfolgt; bei einem Wechsel von einem Netzwerk zu einem anderen Netzwerk oder Subsystem hingegen geht das Netzwerk davon aus, dass ein interner Wechsel zwischen Netzwerkelementen stattfindet.

    Daher geschieht beim Netzwechsel abstrahiert folgendes:

    1. Der Avatar des Netdivers erreicht den NAXP (NAX Point) und leitet ein Netzwechsel ein.
    2. Die Anfrage wird vom NAXP des Netzwerks A an das NAXP des Netzwerks B übermittelt.
    3. Das NAXP B erlaubt oder blockiert die Anfrage.
    4. Erlaubt das NAXP B den Eintritt, so wird ein Datentunnel (NAXT – NAX Transferchannel, vgl. VPN) aufgebaut, durch welches das ‚ganz normale‘ LogOn Verfahren ausgeführt wird; also:
    4.1 PreP
    4.2 Splash
    4.3 Dive

    Es geschieht noch mehr.

    5. NAXP A stellt zum ROM des Users eine Standbyleitung bereit.
    5.1 Handelt es sich um das vROM (Netzwerk A) eines NetDivers, wird diesem mitgeteilt, dass es offline geht, da aufgrund der APID Vereinbarungen ein User nur ein aktives Bewusstsein im GlobalNet führen darf; damit wird das vROM A im Wesentlich geflasht, so dass das vROM A nur eine Datenleitung darstellt; im neuen vROM B wurden alle Avatar Informationen hochgeladen, aktiviert und für das Netzwerk B verfügbar gemacht; der NetDiver kann abhängig von den Netzwerk B Eigenarten handeln;
    5.2. Handelt es sich um das ROM eines passiven Users (Terminal, Cyberdeck), so kann der User ganz normal fortfahren; er sieht sich vor dem Problem, dass die Netzwerkaktivitäten ihn erheblich bremsen werden, da seine Leitung von seinem Terminal bis zum aktuellen Standort im Netz eine aktive Leitung und nicht eine passive Stand-by Leitung wie beim netDiver ist. Das heißt, dass jede Anfrage von Programmen oder Handlungen, die von seinem Terminal ausgehen, durch NAXT gefiltert wird; jede Anfrage wird erneut durch die beteiligten NAXPs überprüft, autorisiert oder blockiert; hier tatsächlich wird offenkundig, weshalb trotz der Risiken der aktive NetDiver Vorteile hat.

    Wenn der aktive NetDiver aus dem Netzwerk B wieder zurück will, ist das Verfahren -in der Theorie – deutlich einfacher. Durch den NAXT besteht bereits eine offene Leitung zu dem Netzwerk A. So kann jede beliebige Anfrage aus dem neuen Netzwerk ohne weitere Sicherheitsprüfungen in das alte Netzwerk durchgeführt werden. Daher wendet sich der NetDiver lediglich an den NAXP des Systems B, aktiviert den Datenfluss über NAXT in das NAXP A, wodurch er automatisch in das alte Netzwerk hochgeladen wird.

    Der aufmerksame Leser wird jetzt natürlich fragen, wie das möglich ist, da ja das vROM des NetDivers im alten Netzwerk geflasht worden ist. Die Antwort ist einfach: Es ist im Grunde das gleiche, wie mit der Papierkorbfunktion von Betriebssystemen unserer Zeit. Die Daten werden gelöscht und temporär inaktiv vorgehalten, bis sie endgültig gelöscht werden oder wieder neu geladen werden. Wenn man so will, so handelt es sich um eine Art Kurzzeitgedächtnis-Funktion des Net-AIOS.
    Spitzfindig kann nachgefasst werden: Der NetDiver wird doch aber aus dem neuen Netzwerk gesicherte Daten, Programme, Veränderungen mitnehmen, die in dieser Papierkorbfunktion nicht berücksichtigt worden sind; wenn man so will hat der Avatar nun eine andere Versionsnummer als die ursprüngliche Avatar Version. Auch hier ist die Lösung einfach: Zwischen den NAXPs werden die Unterschiede erkannt und entsprechend synchronisiert – also die neuen Daten werden ergänzt.

    Schwierig wird die Situation jedoch, wenn der NetDiver im neuen System Alarme ausgelöst hat. In diesen Fällen werden alle NAXT aus dem APID Bereich, aus dem der NetDiver kommt, automatisch in einen Stand-By Modus überführt; das Keep-Alive-Signal wird über die Datenleitung noch immer gewährleistet, aber der aktive Datenfluss wird verschlossen. Das ist am besten vergleichbar mit einer verschärften Sicherheitskontrolle am Flughafen.
    Das führt dazu, dass der NetDiver bei der Rückkehr die Autorisierungsprozedur zwischen den beteiligten NAXPs durchführen muss.

    Variante 1: Es gelingt ihm, nicht blockiert zu werden, dann gilt alles oben erwähnte.
    Variante 2: Der NetDiver wird blockiert. Dann muss er zwangsläufig über ein drittes oder viertes Subsystem einen Umweg suchen, sich eine falsche APID erstellen oder aber den NAXT direkt hacken.

    Alles aus Variante 2 kostet Zeit – Zeit, die von Systemsicherheitssystemen (Tri-S) dazu verwendet werden können, die Standby-Leitung bis zum Cyberdeck des Users zurückzuverfolgen.
    Was so einfach klingt, steht vor einer technischen Hürde, die das Leben für NetDiver recht einfach machen kann: Wenn Tri-S von Netzwerk B auf Netzwerk A zugreifen will, dann ist das abstrahiert das gleiche, was ein User/ NetDiver beim Netzwechsel durchführen will. Erschwerend kommt hinzu, dass sich Tri-S auf einem individuellen Stream aufschalten möchte.
    Sind Netzwerk A und Netzwerk B vollkompatibel, dann ist das kein Problem; handelt es sich um Netzwerke, die nicht voll kompatibel sind oder die von unterschiedlichen „Betreibern“/ Eigentümern stammen, dann ist das ein großes Problem. Dann muss Tri-S mit der AI des auslösenden Netzwerks hacken. Hier tritt die AI des Netzwerks gegen die AI des anderen Netzwerks an, als wäre es ein NetDiver.

    Gelingt es dem alarmierten System, sich zum erstbesten geflashten ROM des NetDivers zu verbinden, führt es einen Befehl aus, der über die APID und GlobalNet Abkommen universell gültig ist: Der NetDiver wird an diesen Punkt zurückgeholt – unter Verlust aller zwischenzeitlich erworbenen Daten.
    Handelt es sich bei diesem geflashten vROM auch um das vROM, über das die ursprüngliche Verbindung hergestellt worden ist, so wird über eine Cyber-Bio-Feedbackschleife ein Koma-Befehl an das Cyberimplantat des User übermittelt, welches zum einen die Netsession beendet und zum anderen den NetDiver in einen traumlosen Schlaf überführt; zeitgleich übermittelt Tri-S an die örtlichen Sicherheitssysteme die Positionsdaten des NetDivers; die AI des alarmierten Nets leitet automatisch eine Anzeige durch.

    (Gerüchte besagen, dass es auch andere Cyber-Bio-Feedbackschleifen gibt, die wahlweise das Hirn hacken oder sogar tötliche Befehle aussenden; auch gibt es Berichte, nach denen Schutzgelderpressungen von der AI ausgeführt werden; der Kreativität der Systeme sind hier keine Grenzen gesetzt).

    Sofern der NetDiver sich einen Umweg „nach Hause“ suchen muss oder sich über eine neue gefälschte APID zurückverbindet auf das Ausgangsnetzwerk, so muss er so dann seinen eigenen vROM hacken, um dem System mitzuteilen, dass er er ist. Das ist üblicherweise kein Problem, da die NetDiver hierfür entsprechende Hintertür-Applikationen oder Zertifikate verwenden.

    Alles das vorausgehend geschilderte bedeutet für einen passiven User, dass hier ein Hack der Systeme untereinander nicht erforderlich ist, um an den User im Falle eines Alarms heranzukommen. Durch die passive Verbindung zum Netzwerk hat der passive User keine Möglichkeit, seine APID zu verfälschen. Dadurch weiß das alarmierte System auf Grundlage der erneuerten APID, wo sich der User befindet. Im Falle eines Alarms und bei erfolgreicher Erkenntnis des Systems, dass der passive User den Alarm ausgelöst hat, wird der NAXT getrennt; die vorangeschalteten Netzwerke werden informiert und trennen jede Verbindung ebenfalls. Zeitgleich mit dieser Trennung wird ein Flash-Befehl an das Terminal/ das Cyberdeck übermittelt, um alle gewonnen Daten aus der Netzverbindung zu verschlüsseln und dann zu zerstören, damit der User keinen Nutzen daraus ziehen kann.
    Freundlicherweise verwenden die Systeme hierfür Delay-Simulatoren. Diese simulieren dem User für eine kurze Zeit eine erfolgreiche Net-Session. Und plötzlich ist alles schwarz …

    Aus diesen Ausführungen dürfte klar sein, dass theoretisch Verbindungen über eine Vielzahl von Netzwerken erfolgen können. Das führt uns zwangsläufig zum zweiten Problemkreis:

    b) Welche Probleme stellen sich dort automatisch ein?

    Die unterschiedlichen Netzwerke verfügen über unterschiedliche Standards – ihre Hardwaremöglichkeiten (Rechenleistung für Cloud-Computing, gemessen in KI (Komplexitäts-Index)), die verwendeten AIOSes, verwendete Applikationen und damit der Umfang an möglichen Handlungsformen (Ein Bank-AIOS wird keine Bagger-Routinen verwenden), Sicherheitsvorkehrungen, Speicherverwaltung für APIDs und vROMs und damit die Zahl möglicher aktiver User.

    Das führt zwangsläufig dazu, dass ein roher Avatar nach seinem Upload in das erste Netzwerk A bereits stark verändert worden ist (angepasst) und bei jedem Wechsel in Netzerke B, C, D u.v.m. weiter verändert wird. Im schlimmsten Fall kann das bedeuten, dass mit jedem Netwechsel ein Downgrade erfolgt, was wiederum dazu führen kann, dass selbst die Minimalkonfiguration des Avatars nicht mehr ausgeführt werden könnte (NAXP T weist Anfrage von NAXP S zurück, da es das erkennt). Aus diesem Grund sind NetDiver stets so ausgestattet, dass sie in Datenarchiven diverse Hilfsmittel/ Alternativ-Avatare/ Mods mitführen, um solche Hindernisse zu überwinden.

    Daraus ergibt sich, dass auch Upgrades durch Netzwechsel möglich sind.

    Diese offenkundigen Probleme zwischen NetDivern und Net-Systemen sind jedoch das kleinere Problem.

    Das größere Problem stellt die Korrespondenz zwischen den Systemen dar. Im ersten Abschnitt ist es bereits angedeutet worden:

    Beim Netwechsel stehen die AIs autonom einander gegenüber. Will die eine AI Routinen, Prozeduren oder Programme auf der anderen AI ausführen, muss die eine AI die andere „hacken“, wenn sie nicht „gleichgeschaltet“ sind.

    Diese Gleichschaltung kann aufgrund unterschiedlichster Hintergründe erfolgen: Verträge zwischen den AIs, die sich gegenseitig vertrauen; identischer Eigentümer der Systeme im Real-Life; hierarchische Strukturen.

    Die reine absolute Gleichartigkeit der AIOSes und Tri-S Applikationen reicht nicht aus, da beide AIOSes immer noch ihre eigenen Persönlichkeitsprofile verwenden. Tatsächlich ist das daher gar nicht so einfach. Denn die AIs mit ihren „semi-Persönlichkeiten“ verhalten sich auch entsprechend. Selbst befreundete oder hierarchisch organisierte Systeme stehen sich weitestgehend autonom gegenüber. Das führt dazu, dass die Netzwerke zwar einerseits durch GlobalNet miteinander verknüpft sein können, sie aber andererseits trotzdem so ausgerichtet sind, dass sie sich selbst individuell schützen. Es liegt in ihrer Natur wie bei mutmaßlich jedem Individuum: Selbstschutz zur Selbsterhaltung.

    Der Hintergrund dafür ist, dass die Systeme sich nicht gegenseitig beliebig ausspionieren oder beeinflussen können sollen. Ferner wird so verhindert, das Rogue-AI beliebig in den Netzwerken aktiv werden können.

    Grau ist alle Theorie. Denn es gibt zahlreiche eigenständige Netzwerksysteme, die nicht mit dem GlobalNet verbunden sind (Militärnetzwerke, spezielle Kommunikationssysteme, jedes Raumschiffsystem für sich genommen, jedes Stationssstem für sich genommen, Satellitensysteme etc. pp.), die aber trotzdem auf technischen Umwegen über das GlobalNet erreichbar sein können. Und diese Systeme für sich sind so eigenständig, dass sie durch andere Netzwerksysteme in kaum einer Form beeinflusst werden können; das setzt Programmier- und Adaptionsfähigkeiten voraus, die bisher nur NetDiver, selbst passive User oder eigenständige Rogue-AIs zeigen konnten.

    c) Wo liegen die Hack-Potentiale für Grey- und Blackheads?

    Ein NetDiver, der einen Netwechsel durchführt, hat zunächst die gleichen Hackpotentiale wie bei einem normalen LogOn-Verfahren. Das, im Übrigen, erschwert auch die Rückverfolgung durch Tri-S.

    Darüber hinaus kann der (gute) NetDiver auch die NAXP Anfragen direkt beeinflussen, indem er das System mit vorgefertigten oder gefälschten Anfrageprotokollen füttert. Das hat zur Folge, dass bei dem LogOn auf das neue System eine falsche APID generiert wird.

    Ok, Wall of words. Und ich bin auch gerade trocken gelaufen. Mir kommt der Verdacht, dass ich irgendetwas vergessen habe. Aber das ergänze ich, sofern es mir wieder in den Sinn kommt.

    Viele Grüße
    Fred


    Nachtrag: 25. September 2011
    Für den hier verfassten Artikel von Fred aka Clem C. Schermann gelten die nachstehenden CC-Lizenz-Bestimmungen:
    Diese Inhalte von Clem Carlos Schermann steht unter einer Creative Commons Namensnennung-Nicht-kommerziell-Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.

    #2396
    imported_mirc
    Mitglied

    Pheeew! Fred-Man…
    …Dein kreatives Potenzial erschlägt den unbedarften Leser – den es hier jedoch nicht geben sollte 😉

    Okay, ich habe die anderen Replys noch nicht gelesen, daher nur eine kurzes Vorabstatement und ein leichter Weiterdenkanstoß.

    Gelingt es dem alarmierten System, sich zum erstbesten geflashten ROM des NetDivers zu verbinden, führt es einen Befehl aus, der über die APID und GlobalNet Abkommen universell gültig ist: Der NetDiver wird an diesen Punkt zurückgeholt – unter Verlust aller zwischenzeitlich erworbenen Daten.
    Handelt es sich bei diesem geflashten vROM auch um das vROM, über das die ursprüngliche Verbindung hergestellt worden ist, so wird über eine Cyber-Bio-Feedbackschleife ein Koma-Befehl an das Cyberimplantat des User übermittelt, welches zum einen die Netsession beendet und zum anderen den NetDiver in einen traumlosen Schlaf überführt; zeitgleich übermittelt Tri-S an die örtlichen Sicherheitssysteme die Positionsdaten des NetDivers; die AI des alarmierten Nets leitet automatisch eine Anzeige durch.

    Zumindest die interstellaren GlobalNet Abkommen schützen USC-intern die Persönlichkeitsrechte von Individuen. Soll heißen die Verfassung der USC ist recht liberal und begünstigt Besitz, Freiheit und Schutz der Person oder persönlicher Daten. Ähnlich sind die Gesetze der Galaktischen Gesellschaft aufgestellt. Allerdings beider mit einem großen aber.

    Gemäß des föderalen Gedanken können Mitglieder der Konföderation alle Belange selbst regeln oder regulatorisch ergänzen für die es keine Entsprechungen in den Gesetzen der Konföderation gibt. Bitte korrigier mich hier wenn ich hier Unsinn verfasse, das ist ein sehr stiefmütterlich behandeltes und recherchiertes Gebiet für mich. In meiner Vorstellung gelten diese USC-Regelungen „zwischen den Welten“ (entre los tierras 😉 ) d.h. lokale Regelungen werden davon abweichen. Beim Transfer von Daten auf einem Raumschiff jedoch gelten unbedingt USC-Regelungen (außerhalb eines lokalen Souveränitätsbereiches). Sind die Daten also unterwegs Live-Daten, so fällt die Koma-Geschichte flach. Handelt es sich um Transportdaten (7Z-Files oder Protected Data Containers, also grob um „gepackte Daten“) so müssen die Daten lediglich den Gesetzen der Start- und Zielgesellschaft entsprechen, was kaum Dive-Relevant sein dürfte.

    Intuitiv möchte ich die Komatisierung eines NetDivers der illegale Handlungen vollzieht als Selbstjustiz anprangern. Vielleicht hat es zudem auch noch spieltechnische Vorteile wenn der Hacker die Chance hat den Konsequenzen eines verbockten Dives zumindest RL zu entgehen indem er sich den zweifellos heraneilenden Behördenvertretern zu entziehen versucht.

    Ich plane den Umfang der Möglichkeiten der lokalen Gesetzesvertreter primär davon abhängig machen welche Regierungesform, welcher Eigentumsstatus und welches Control-Rating im gehackten Netz gelten (bzw. auf der Welt in dessen GlobalNet sich der Diver bewegt. Lass uns dazu den Bereich AlienSocieties als Platform verwenden.

    #2397
    Fred_Krug
    Mitglied

    Hey.

    Zumindest die interstellaren GlobalNet Abkommen schützen USC-intern die Persönlichkeitsrechte von Individuen. Soll heißen die Verfassung der USC ist recht liberal und begünstigt Besitz, Freiheit und Schutz der Person oder persönlicher Daten. Ähnlich sind die Gesetze der Galaktischen Gesellschaft aufgestellt. Allerdings beider mit einem großen aber.

    Tja. Aber gehören „geklaute“ Daten oder gewonnene Daten zum Bereich der persönlichen Daten? Wenn das nicht eindeutig beantwortet werden kann, dann wird wahrscheinlich die Frage über die „Signierungen“ von Programmen und Funktionen gelöst werden.
    Wenn Kalle beispielsweise einen Ordner mit persönlichen Daten findet und einpackt, dann gehören sie ihm. Ist dieser Ordner aber auf bestimmte Weise kenntlich gemacht, so erlaubt dies den (begrenzten?) Zugriff von außen – wahlweise durch den originalen Eigentümer oder aber durch Netz-Beauftragte.
    Fraglich ist ja auch: Haben AIs (z.B. Gebäudemanagement), die komplett autonom sind, auch einen „Persönlichkeitsbereich“? Und wird der Schutz ihrer Daten ausschließlich in ihre Verantwortung überstellt?

    Ist das der Fall, oder anders: ist es grundsätzlich so, dass jeder oder jedes System für sich selbst in der Verantwortung steht, dass er „nicht bestohlen“ werden kann? Und wenn das so ist, warum sollte der Dieb dann Persönlichkeitsrechte geltend machen können?

    Schwierig … Aber in einem nicht regulierbaren und scheinbar pluralistischen System nicht anders möglich.

    Jedenfalls greife ich das auf und sehe ein, dass es „aus technischen“ Gründen nicht so ohne weiteres möglich ist, einen Bio-Feedback Impuls zu setzen, der den NetDiver kurzfristig ausschaltet. Die Lokalisierung jedoch halte ich für ein einfaches Mittel. Hier muss der NetDiver halt dafür sorgen, seinen Zugang zu faken, um das aufspürende System in die Irre zu führen.

    Da gärt einiges … Bin noch nicht fertig geschweige denn fix und fertig. 😉

    Viele Grüße
    Fred

Ansicht von 3 Beiträgen - 1 bis 3 (von insgesamt 3)
  • Du musst angemeldet sein, um auf dieses Thema antworten zu können.