Cahier des charges

Que doit-être le chiffrement dans Shadowrun ?

• Un moyen de rajouter de la tension en rallongeant le temps de Hacking.
• Un moyen de distiller l’information dans une enquête, en retardant le temps d’arrivée d’une nouvelle donnée.
• Un moyen de pousser les PJs à agir, pour obtenir le code en lui-même ou alors un moyen de faciliter ou accelérer le décryptage.
• Un moyen de justifier l’utilisation universelle des Commlinks, y compris pour la transmissions d’informations sensibles.

Comment mettre ceci en place ?

• En permettant un décryptage des communications ou des nœuds en quelques secondes afin de ne pas bloquer les infiltrations ou le Hacking sur place.
• En permettant un décryptage plus long de certaines données.
• En permettant au hacker ou aux autres PJs d’influer sur la possibilité ou le temps de décryptage via certaines actions.
• En empêchant ou en rendant plus difficile le décryptage de certaines communications très sensibles.

Les trois premiers points semblent pouvoir se résoudre en influant sur les paramètres du décryptage : modificateurs et intervalle de temps. Mais pour le dernier point, il faut jouer sur autre chose : la considération du temps de décryptage par rapport à la durée de la communication.

1. Temps de décryptage et durée de la communication

Cette partie n’ajoute aucune règle mais propose une certaine interprétation des règles existantes

Imaginons que Joe Lambda envoie un ordre de virement à sa banque. Joe Lambda possède un Commlink ordinaire avec un programme de chiffrement d’indice assez bas (ou tout du moins limité par celui de son Commlink). Si n’importe quel hacker pouvait influer sur cet ordre, les Commlinks ne seraient pas le moyen de paiement de base.

Mais comment le hacker doit-il s’y prendre s’il veut intercepter cette communication ?
Selon le livre de base de Shadowrun, il lui faut tout d’abord décrypter la communication [1] Ceci prendra un ou plusieurs tours de combat. Seulement après il pourra lancer l’action simple d’interception de la communication.

Or, l’ordre de virement peut-être envoyé en moins des trois secondes qui forment le round de combat. Le temps que le hacker soit prêt à intercepter la communication, celle-ci est déjà terminée. L’économie mondiale n’est pas menacée par les hackers.

Mais cette même logique ne rend pas impossible toute tentative d’interception de communication ?
Fort heureusement non, puisque la plupart des communications ont une durée plus longue qu’un seul round de combat. Ceci permet simplement au MJ de donner une limite de temps pour l’interception d’une communication et de donner une utilité aux programmes de chiffrement de bas niveau.

Mais pourquoi une communication entre deux personne n’utiliserait pas ce système en renégociant le chiffrement entre chaque message ?
C’est possible, mais si le hacker déchiffre les premiers messages, il pourra alors sûrement déchiffrer les prochains (ou tout du moins les déchiffrer plus facilement) et arrivera finalement à remonter jusqu’au code utilisé actuellement. C’est pourquoi, pour ne pas trop compliquer les choses, on ignorera donc cette possibilité.
Cependant, une fois une communication décryptée, le MJ pourra utiliser ceci pour demander au hacker de refaire un test de Décryptage (avec un bonus de +4) de temps à autres.

2. Nouvelles règles

Comme vu précédemment, il peut-être intéressant de jouer sur deux aspects : les modificateurs du tests et les intervalles de temps.

2.1 Modificateurs

Voici quelques modificateurs proposés dans l’optique de permettre au MJ de moduler la difficulté de décryptage d’un élément et au hacker d’influer sur ses chances de décryptages via diverses initatives.

• Côté chiffrement (les modificateurs s’ajoutent au seuil nécessaire pour décrypter)
  • Connection présécurisée : +2
    Une connection est considérée présécurisée quand les nodes n’ont pas à négocier la clef lors de l’établissement de la connexion. Autrement dit, quand les clefs ont été fixées avant la connexion (attention, un clef digne de ce nom est très très longue... ça peut pas être un code rapidement échangé comme ça entre deux personnes. Il est nécessaire de la stocker sur un support informatique quelconque pour la transmettre... ou alors se baser sur un passage d’un livre, une image, une donnée biométrique ou quelque chose d’une similaire.).
    Ce sera le cas des drones du réseau d’un rigger, des Commlinks d’une équipe de runners, d’un client avec sa banque, etc.

• Contenu fixe : +4
  Un fichier est plus dur à décrypter rapidement qu’un système qui doit répondre aux requêtes extérieures. Attention, les nodes ne rentrent pas dans cette catégorie là : le node doit s’adapter aux événements et ne présente donc pas un contenu fixe.

• Coté décryptage (les modificateurs s’appliquent à la réserve de dés du test de décryptage)
  • Connaissance du contenu : +1 à +4
    Si le hacker connait une partie du message à décrypter, il lui sera plus facile de décrypter le message. Par exemple, s’il cherche à décrypter le canal de communication entre un rigger et ses drones, il pourra profiter du fait de pouvoir faire correspondre les messages envoyés et les actions effectués par les drones. Celà s’applique aussi aux messages textuels : s’il sait quels mots il risque de retrouver, cela peut aider à décrypter le message. Selon le niveau d’information nécessaire, le bonus peut varier de +1 à +4.

• Données disponibles : -2 à +2
  Si le hacker ne possède qu’un seul fichier chiffré avec la clef, le déchiffrement sera bien plus difficile que s’il a de nombreuses références sur lesquelles se baser. Le modificateur négatif s’applique pour des messages courts, le modificateur positif s’applique lorsqu’il y a plusieurs messages ou fichiers. Cela fait aussi qu’un rigger donnant beaucoup d’ordres à ses drones, ou une équipe communicant beaucoup à plus de chances de voir son chiffrement sauter.

• Méthode aggressive (données non statiques) : +2 Si le chiffrement est fait en temps réel, le hacker peut essayer de le manipuler un peu pour s’aider dans son travail. Cependant, cette technique peut attirer l’attention vers lui. A chaque fois que le hacker utilise ce bonus, le node de réception peut effectuer un test d’Analyse+Firewall contre l’indice du programme de Discretion du hacker. Les succès du node s’accumulent (façon jet étendu) en cas d’utilisation répétée de ce bonus lors du jet étendu de décryptage.

2.2 Intervalles de temps

Je me permets ici de modifier un peu le principe des règles de base sur les tests étendus en rajoutant une particularité : l’intervalle augmente au fur et à mesure des jets.

L’ordre est le suivant :

1 : un tour de combat
2 : une minute
3 : une heure
4 : un jour
5 : une semaine

Dans le cas des fichiers, le passage à l’intervalle supérieur se fait à chaque nouveau jet. Dans le cadre de la communication ou d’un nœud, le passage se fait tous les deux jets.
Bien entendu, le MJ est libre de faire varier ces intervalles en fonction du nombre de succès obtenus par le hacker : s’il ne manque qu’un succès pour décrypter un nœud au bout de quatre jets, le décryptage pourra lui prendre quelques minutes de plus plutôt qu’une heure, les succès excédentaires servant à réduire la durée du dernier intervalle.

Cette solution est encore loin d’être parfaite, mais je la trouve déjà plus intéressante que la situation d’origine.
Je n’ai cependant pas eu trop l’occasion de la beaucoup tester en situation. Si jamais vous avez des remarques ou des suggestions, n’hésitez pas à venir en discuter sur les forums, dans la section Atlernatif.