Problem mit doc.encrypt | Verschlüsselung eines Dokumentes

[Alexander 28]

Jetzt muss ich doch einmal posten. Irgendwie sehe ich den Wald vor lauter Bäumen nicht. Ich habe Dokumente, die optional vom Benutzer mit dem persönlichen geheimen Schlüssel verschlüsselt werden können. Dieser setzt seinen Schlüssel in das Feld 'SecretEncryptionKeys'. Verschlüsselt wird das Feld 'body'. Die entsprechende Feldkennzeichnung, dass das Feld verschlüsselt werden soll, existiert am Feld. Wenn das Dokument nun gespeichert wird, sollte der Inhalt des body-Feldes verschlüsselt sein. Ich war auch der festen Überzeugung, dass das mal funktioniert hat. Zwischenzeitlich musste ich aber feststellen, dass das nicht klappt und jeder der ein Leserecht auf das Dokument hat, den Inhalt des Haupttextfeldes sehen kann?!!!!

Nun habe ich hier im Forum gelesen, dass ich zusätzlich doc.Encrypt aufrufen muss, damit die Verschlüsselung am Dokument tatsächlich vorgenommen wird. Dummerweise kann ich diese Funktion aber nicht aufrufen, solange das Dokument im Frontend noch geöffnet ist. Notes liefert mir in dem Fall einen entsprechenden Fehler.

Ich hab dann mal einen kleinen Testagenten gebaut und das Dokument in der Ansicht markiert und die Funktion doc.Encrypt aufgerufen und das Doc gespeichert. Nun funktioniert es und der Inhalt wird dem Benutzer, der den persönlichen Schlüssel nicht hat nicht angezeigt. Das ist aber eigentlich nicht das, was ich will. Ich möchte, dass das Dokument direkt im Rahmen der Speicherung verschlüsselt wird.

Wie kann ich also das Dokument tatsächlich verschlüsseln, in dem Moment, wo es gespeichert wird und nicht erst im Nachgang, nachdem das Dokument geschlossen wurde?

Wahrscheinlich ist die Lösung ganz einfach, aber irgendwie habe ich scheinbar ein Brett vor dem Kopf. Was mich außerdem wundert ist, dass das ganze mal funktioniert hat, dessen bin ich mir ziemlich sicher ohne dass ich explizit die Funktion doc.encrypt aufrufen musste!?

[pram]

Das mit der Verschlüsselung ist eine ganz kniffelige Sache und man muss unterscheiden zwischen Frontend und Backend-Aktion:

Ein UI-Save, bzw. Frontend-Save verschlüsselt das Dokument. Damit dies reibungslos funktioniert, muss es in der Maske das Feld "SecretEnctyptionKeys" geben.
Ein "doc.SecretencryptionKeys = ..." bzw. "FIELD SecretEncrytionKeys := ... " reicht nicht (je nach Notesversion). Das Feld muss wirklich in der Maske existieren.

Greift man anschließend im Backend per LotusScript auf das Dokument zu (Ansichtsaktion/Agent), wird es automatisch wieder entschlüsselt (sofern man einen der angegebenen Schlüssel hat). Diese (nervige) automatische Entschlüsselung kann man leider nirgends abschalten.

=> Du musst also vor jedem doc.save prüfen, ob das Dokument verschlüsselt war, automatisch entschlüsselt wurde und eine Neuverschlüsselung erforderlich ist.

Code

if (doc.SecretEncryptionKeys(0) <> "") or (doc.PublicEncryptionKeys(0) <> "") then  ' Verschlüsselung ist aktiviert
   if not doc.isEncrypted then ' Das Dokument ist aber nicht verschlüsselt bzw. wurde automatisch entschlüsselt
      call doc.encrypt() ' Versuchen, das Dokument wieder zu verschlüsseln
   end if
end if

Nun gibt es folgenden "gemeinen" Sonderfall:
Angenommen, Person A gibt mehrere Schlüssel in SecretEncryptionKeys (z.B: SC1 + SC2) an und speichert das Dokument.
Dabei wird das Dokument mit SC1, SC2 verschlüsselt (um ganz genau zu sein wird es zusätzlich noch mit dem öffentliche Schlüssel von Person A verschlüsselt. Man kann sich also selbst nicht "aussperren")

Führt nun Person B eine LS-Aktion auf dem Dokument aus und hat nur SC1, so kann Person B das Dokument zwar entschlüsseln, aber nicht mehr verschlüsseln, da "doc.encrypt()" mit der Fehlermeldung abbricht, dass SC2 kein bekannter Schlüssel ist (dieser steht ja noch im Feld SecretEncryptionKeys)
Mit LotusScript lässt sich so ein Dokument nicht mehr ändern

Die einzige Möglichkeit um bei solchen Dokumenten irgenwelche Flags zu ändern ist Formelsprache, da diese das Dokument nicht entschlüsselt. Man kann zur Not in LotusScript mit Evaluate + @SetDocField arbeiten um Werte in Dokumenten zu ändern, ohne die Verschlüsselung aufzuheben.


Gruß
Roland

[Alexander 28]

Hi Roland, vielen Dank für die ausführliche Antwort. Ich habe die Verschlüsselung nun im QueryClose des Dokuments eingebaut

Code

Dim Agent As NotesAgent	
Set Agent = db.GetAgent("(EncryptThisDoc)")

If uidoc.EditMode Then
	Call Agent.Run(doc.NoteID)
End If

Das ist ja echt eine riesige Schei .... Wenn ich mir überlege, an wie vielen Stellen ich in der Anwendung im BackEnd auf die Dokumente zugreife, stellt das ein echtes Problem mit der automatischen Entschlüsselung dar. Ich habe mir nun gedacht, dass ich einfach einen periodischen Server Agenten baue, der alle 5 Minuten die Verschlüsselungen wieder gerade zieht, das geht ja aber auch nicht, da dieser ja im Besitz der persönlichen Schlüssel sein muss. Also bleibt offensichtlich nichts anderes übrig, als tatsächlich alle Routinen noch einmal durchzuschauen und die Verschlüsselung zu checken und sofern erforderlich neu zu setzen. Sehr ärgerlich!!!

Gibt's vielleicht noch einen anderen Weg ursprünglich verschlüsselte Dokumente auch weiter verschlüsselt zu halten, nachdem per Skript darauf zugegriffen wurde?

[PromITheus]

Hallo Alexander,

ich habe ein paar grundsätzliche Anmerkungen zur Verschlüsselung.

Über das $Seal-Feld lässt sich schnell erkennen ob das Dokument verschlüsselt ist (vorhanden = verschlüsselt). Wir lassen im Dokument ein Schlosssymbol einblenden wenn das Feld vorhanden ist. So kann der Benutzer direkt erkennen ob das Dokument verschlüsselt ist.

Warum nutzt du das Feld SecretEncryptionKeys? Wäre nicht PublicEncryptionKeys besser geeignet? Ich habe das immer so verstanden, bitte korrigiert mich wenn ich falsch liege:
Willst du einfach mit der ID des Users verschlüsseln benutzt du PublicEncryptionKeys und trägst dort den Usernamen ein.
Hast du einen extra Verschlüsselungsschlüssel selbst erstellt, verteilst du diesen an die Personen die ihn benötigen (z.B. ein Schlüssel für die Personalabteilung um Gehaltsfelder einsehen zu können). Diesen Schlüsselnamen trägst du in SecretEncryptionKeys ein. Dieser Schlüssel muss immer in die Benutzer-ID importiert werden.

Das Problem "Verschlüsselung verschwindet beim erneuten Abspeichern" gibt es auch direkt in der Mailbox! Hat man eine verschlüsselte Mail erhalten und speichert diese erneut ab, verschwindet Verschlüsselung. Fiese Falle 

[pram]

Hallo Alexander

... Ich habe die Verschlüsselung nun im QueryClose des Dokuments eingebaut

Dies brauchst du normalerweise nicht, wenn du keine Backend-Saves machst und das Dokument NUR über UI-Save gespeichert wird (allerdings muss das Feld in der Maske existieren)
Das Dokument sollte dann zu keiner Zeit unverschlüsselt sein. Wenn doch, hast du was falsch gemacht. Und QueryClose wird ja auch nicht immer zuverlässig ausgeführt (Clientabsturz), ausserdem würde das Dok bis zum Schließen immer noch unverschlüsselt in der DB liegen.

Das ist ja echt eine riesige Schei .... Wenn ich mir überlege, an wie vielen Stellen ich in der Anwendung im BackEnd auf die Dokumente zugreife, stellt das ein echtes Problem mit der automatischen Entschlüsselung dar.

Du sagst es...

Ich habe mir nun gedacht, dass ich einfach einen periodischen Server Agenten baue, der alle 5 Minuten die Verschlüsselungen wieder gerade zieht, das geht ja aber auch nicht, da dieser ja im Besitz der persönlichen Schlüssel sein muss. Also bleibt offensichtlich nichts anderes übrig, als tatsächlich alle Routinen noch einmal durchzuschauen und die Verschlüsselung zu checken und sofern erforderlich neu zu setzen. Sehr ärgerlich!!!

Und ehrlich gesagt.... unsicher. Wer garantiert dir, dass während der 5 min keiner das Dokument abgreift. Außerdem wird das Dokument dann zusätzlich mit
der ID des Servers verschlüsselt und kann auch von diesem wieder entschlüsselt werden. (Bzw. von einem Admin, der Zugriff auf den Server hat)

Und es ist ja gerade der Sinn der Verschlüsselung, dass ich im Notessystem Dokumente ablegen kann, auf welche Admins usw. keinen Zugriff haben und sich diesen auch nicht verschaffen können. (OK er könnte ein ID-File wiederherstellen, aber auch das kann man mit einem Mehraugenprinzip absichern)

Wir protokollieren in unseren Anwendungen dies sogar als Sicherheitsrisiko, wenn der Server auf verschlüsselte Dokumente zugreifen kann.

Gibt's vielleicht noch einen anderen Weg ursprünglich verschlüsselte Dokumente auch weiter verschlüsselt zu halten, nachdem per Skript darauf zugegriffen wurde?

Mit Standard-Lotusscript => Nein. Ich habe mal versucht, mit Hilfe der C-API die Felder auszulesen und in ein NotesDokument-Object zu kopieren, so dass man mit Lotusscript weiterarbeiten könnte, das hat mehr schlecht als recht funktioniert.

Wir hatten das Glück, dass bei unserem Framework alle SAVE-Aufrufe über eine zentrale Stelle laufen, an der wir relativ einfach sicher stellen können, dass verschlüsselte Dokumente verschlüsselt bleiben 
Den Sonderfall, dass man nicht alle Schlüssel hat, haben wir dann so abgedeckt, dass wir die Werte mit @SetDocField schreiben.

Über das $Seal-Feld lässt sich schnell erkennen ob das Dokument verschlüsselt ist (vorhanden = verschlüsselt).

Das ist eine sehr gute Idee, haben wir ähnlich gemacht, Wenn Keys gesetzt sind und kein $Seal vorhanden ist, dann stimmt da was nicht.
Auf @isAvailable($Seal) kann man leider nicht in der Ansicht zugreifen, da dies kein Summary Flag hat....
Inzwischen weiß ich aber, dass man das Vorhandensein eines Items (egal ob summary oder nicht) mit @ToLowerCase(@DocFields)="$seal" überprüfen kann.

Die Select-Formel
SELECT (PublicEncryptionKeys != "" | SecretEncryptionKeys !="") & !( @ToLowerCase(@DocFields)="$seal" )
müsste dir sofort alle falsch verschlüsselten Dokumente anzeigen.

Noch ein Hinweis: Der Inhalt der Felder "PublicEncryptionKeys" und "SecretEncryptionKeys" ist nur zum Zeitpunkt der Verschlüsselung relevant und kann nachträglich beliebig geändert werden (wenn da z.B. drin steht, dass das Dok mit dem und dem Schlüssel verschlüsselt wurde, muss das nicht unbedingt stimmen)

Warum nutzt du das Feld SecretEncryptionKeys? Wäre nicht PublicEncryptionKeys besser geeignet? Ich habe das immer so verstanden, bitte korrigiert mich wenn ich falsch liege:
Willst du einfach mit der ID des Users verschlüsseln benutzt du PublicEncryptionKeys und trägst dort den Usernamen ein.
Hast du einen extra Verschlüsselungsschlüssel selbst erstellt, verteilst du diesen an die Personen die ihn benötigen (z.B. ein Schlüssel für die Personalabteilung um Gehaltsfelder einsehen zu können). Diesen Schlüsselnamen trägst du in SecretEncryptionKeys ein. Dieser Schlüssel muss immer in die Benutzer-ID importiert werden.

SecretEncryptionKeys ist meist schon die flexiblere Lösung. Die Mitarbeiter der Personalabteilung ändern sich. Dann muss nur der Schlüssel weitergegeben werden. Andernfalls müsste man die Dokumente alle neu verschlüsseln.

Aber auch bei PublicEncryptionKeys läuft man Gefahr, dass man das Dok zwar ent- aber nicht mehr verschlüsseln kann. Und zwar dann, wenn einer der darin gelisteten Mitarbeiter ausgeschieden ist und der öffentliche Schlüssel nicht mehr im Adressbuch exisitiert.

Die Notes-Verschlüsselung halte ich zwar für sehr sicher, man muss aber höllisch aufpassen, dass man sie durch falsch programmierten Anwendungscode nicht untergräbt.
(Weil man die schei... automatische Entschlüsselung nicht abschalten kann)

Gruß
Roland

[Alexander 28]

Hi PromITheus , hi Roland!

Danke für die vielen und detaillierten Infos. Ich werde mir das nun mal ganz genau anschauen und sehen, welche der vorgeschlagenen Wege ich einschlage.

Herlichen Dank, Alex