Verschlüsseltes Feld PublicEncryptionKeys im Backend aktualisieren

[Legolas]

Hallo Forum,

trotz langer Recherche bin ich nicht weitergekommen. Ich hoffe, Ihr könnt helfen.
Es geht um verschlüsselte Felder in einem Notes-Dokument.

Folgende Situation:
Eine Anwendung beinhaltet Dokumente in den das Body-Feld (und nur dieses) verschlüsselt abgelegt wurde (Text + Attachments).
Bisher wurden die zugriffsberechtigten User vom Ersteller des Dokuments manuell eingetragen (Autoren und Leserfeld).
Das hat auch soweit funktioniert.

Feld: PublicEncryptionKeys
Das Feld enthält alle User (Autoren und Leser) des Dokuments. Die Namen der einzelnen User und der aufgelösten Gruppen sind hierarchisch als Liste in diesem Feld hinterlegt. Zudem wird immer als Notanker der „SuperAdmin“ User in das Autoren- und PublicEncryptionKeys mit eingetragen.

Feld: $SealData existiert nach dem Speichern aus dem UI.
 
Ziel:
Die Anwendung soll soweit erweitert werden, dass die Berechtigungen im Backend via periodischem Agenten neu gerechnet werden können.
Wenn sich z.B. die Mitglieder einer Gruppe ändern.


Problem:
Löse ich im Backend z.B. eine geänderte Gruppe auf und trage die User in das Autoren-  und in das PublicEncryptionKeys Feld ein.

Wird vor dem Speichern der Befehl Call doc.encrypt() aufgerufen erhalte ich einen Fehler.
Wird ohne den Befehl Call doc.encrypt() gespeichert, erhalte ich keinen Fehler.

Bei der Prüfung der Felder sind dann die neuen User auch korrekt eingetragen.
Nur wenn ich mit dem neuen User (der über die Gruppe hinzukam) das Dokument öffne, bekomme ich die Fehlermeldung.
Ich benötige den Dekodierungsschlüssel zum Bearbeiten/Lesen des Feldes.

Der Agent wurde im Namen des „SuperAdmin“ gestartet und auch mit der Signatur des Server.
- Der Agent hat die Sicherheitsstufe 3 (Bechränkte Operationen mit vollst. Admin Rechten zulassen)
- Der Server ist zudem noch als Autor und im Feld PublicEncryptionKeys eingetragen.

Aus der Noteshilfe:

If the script is running on a server, it must have permission to use Encrypt. If the script is part of a scheduled agent running in the background on a server, and the EncryptionKeys property is set with one or more named keys, the server's ID must contain those keys, not the signer of the agent. The agent must also have a runtime security level of at least "Allow restricted operations".

Was ist hier mit der Zeile genau gemeint?

the server's ID must contain those keys

Beim Speichern prüfe ich unter anderem folgendes:

Was muss beim Speichern beachtet werden?

- Muss das $SealData  Feld gelöscht werden?
- Müssen evtl. ander Felder gelöscht werden?

Falls nein, sollte der folgende Code doch funktionieren:

Code

				
Call doc.encrypt() 'Dokument/Felder verschlüsseln
Call doc.save(True, False)

Was mach ich falsch?
Kann mir jemand einen Tipp geben?

Grüße
Bernd

[umi]

the server's ID must contain those keys

Damit die Verschlüsselung funktioniert, brauchen die Benutzer ja einen oder mehrere gemeinsame Schlüssel in ihrem ID File, mit welchem das Dokument bzw. die Felder verschlüsselt werden.
Jeder der diesen Schlüssel hat, kann prinzipiell das Dokument/Felder lesen/bearbeiten

Damit ein Server Agent das Dokument auch verschlüsselt speichern kann, benötigt der Server auch Zugriff auf den gemeinsamen Schlüssel. Ergo muss dieser Schlüssel in der Server.id sein.

[Legolas]

Hallo Umi,

ich verwende aber das Feld PublicEncryptionKeys.
Nach meinem Verständnis wird in diesem Feld der öffentliche Schlüssel der User hinterlegt, die Zugriff auf das verschlüsselte Feld haben sollen.
Wenn ein User nun das Dokument öffnet, wird mit seinem privaten Schlüssel das Feld entschlüsselt.

Im Gegensatz zum geheimen Schlüssel, der den Usern mitgeteilt und in der User-ID gespeichert werden muss und im Feld SecretEncryptionKeys abgelegt wird.
So wie ich dich verstehe, bezieht sich deine Anmerkung auf das SecretEncryptionKeys Feld.

Oder verstehe ich dich falsch?

Grüße
Bernd

[m3]

Aus https://www.ibm.com/support/knowledgecenter/en/SSVRGU_8.5.3/com.ibm.designer.domino.main.doc/H_DOCUMENT_AND_FIELD_ENCRYPTION_OVERVIEW.html
You can encrypt documents with keys in several ways:

• ...
• Using the SecretEncryptionKeys field. The SecretEncryptionKeys field can contain either the name of a key, which is automatically used to encrypt documents, or the field can be blank, allowing users to assign the encryption key. To encrypt a field with a secret key using either method, users must have it stored in their ID file.

Aber:
Public key encryption in non-mailed documents

Basically, if you ONLY have a PublicEncryptionKeys field set, then the backend .encrypt method doesn't recognize it. However, if you have ANY valid SecretEncryptionKeys value, then the PublicEncryptionKeys is also recognized and used.

This provides a workaround in situations where you're encrypting is done centrally -- say if a server ID is encrypting material targetted for users. You simply have to put a shared encryption key on that ID that you don't give to anyone else. Then you can do the following...

doc.encryptionKeys = "[your shared key]"
doc.publicEncryptionKeys = "[target user list]"
Call doc.encrypt
Call doc.removeItem("sharedEncryptionKeys")
Call doc.save (whatever)

http://www-10.lotus.com/ldd/nd6forum.nsf/DateAllFlatweb/29c9f3df1a27f27e85256f50002282dc?OpenDocument

[Legolas]

Hallo m3,

ich komme leider nicht weiter.

Ich bin mir nicht sicher ob ich das hier korrekt verstehe.

1) Muss für diesen Workaround jeder User den SecretKey besitzen?
Falls ja, was für einen Mehrwert hat dann noch der publicEncryptionKey?
Dann ist die Funktion aber nicht praktikabel, da alle User mit dem SecretEncryptionKey ausgestattet werden müssten.

Falls nein, weiterlesen:

In einem Dokument gibt es ein RT-Feld welches verschlüsselt werden soll (Feldmarkierung wird in rot angezeigt).
Ich habe ein Dokument erstellt mit einer Gruppe von 2 Usern und mein eigenen Namen.
Die drei Namen habe ich (Abbriviated) in das Feld doc.publicEncryptionKeys als Array geschrieben und das Dokument gespeichert.
Zudem habe ich in das Feld: doc.encryptionKeys den Namen des SecretKeys geschrieben. Dieser Key ist auch in meiner ID hinterlegt.

Dokument dann gespeichert und geschlossen.

Nun erweitere ich im DD die Gruppe auf drei User.
Im Anschluss starte ich den Backendagenten (mit runonserver) der mir die Gruppe auflöst in die einzelnen Namen und diese wieder in das Feld doc.publicEncryptionKeys schreibt.
Allerdings wird der Dominoserver beim Befehl doc.encrypt dann immer die Fehlermeldung:

Code

Notes error: You don't have any of the specified encryption keys (4000) in line: 34

Diese Fehlermeldung sagt mir ja, dass ich den benötigen SecretKey nicht besitzen würde.
Der SecretKey ist aber in meiner ID hinterlegt.

Nun habe ich versucht, den Agenten in meinem Namen und im Namen des Server laufen zu lassen. Beides mal mit der gleichen Fehlermeldung.

Was mach ich falsch?


Noch ein Verständnisproblem:
Im Code der als Workaround dienen soll, wird das Feld „sharedEncryptionKeys“ gelöscht. Muss das nicht das Feld „SecredEncryptionKey“ sein?

Code

doc.encryptionKeys = "[your shared key]"
doc.publicEncryptionKeys = "[target user list]"
Call doc.encrypt
Call doc.removeItem("sharedEncryptionKeys")
Call doc.save (whatever)

Grüße
Bernd

[Legolas]

Hallo Forum,

ich muss nochmals nachhaken, da mir das Thema unter den Nägeln brennt und ich dringend eine Lösung brauche.
Bin ich etwas der Einzige, der mit verschlüsselten Feldern arbeitet?
Falls nein, muss doch jeder schon auf das gleich Problem gestoßen sein.
Wäre toll von Euch, wenn mir noch jemand helfen könnte.

Danke schon mal für die Rückmeldungen
Bernd

[pram]

Hier ein paar Infos was ich zur Verschlüsselung weiß:

1. Es werden nur Felder verschlüsselt, die das "SEAL" Flag haben (in der Maske bekommen sie "rote Ecken")
2. Die Felder heißen "PublicEncryptionKeys" und "SecretEncryptionKeys" und steuern lediglich die Verschlüsselung (mittels doc.encrypt bzw. uidoc.save - hier müssen sie in der Maske vorhanen sein, Setzen im Backend reicht nicht) Beim Verschlüsseln mit "PublicEncryptionKeys" werden die öffentlichen Schlüssel aus dem Adressbuch geladen (private befindet sich im ID-File). Die SecretEncryptionKeys hingegen müssen verteilt werden und ebenfalls im ID File abgespeichert werden
3. Man kann in einem verschlüsselten Dokument alle nicht verschlüsselten Felder ändern - selbst wenn man es nicht entschlüsseln kann. Man kann auch den Inhalt in PublicEncryptionKeys und SecretEncryptionKeys ändern Der Inhalt dieser Felder muss nicht dem tatsächlichen Verschlüsselungsstand entsprechen
4. Zum Verschlüsseln muss man ALLE Schlüssel haben (PE-Keys bekommt man automatisch aus dem Adressbuch, SE-Keys sind im ID-File)
5. Wen man ein Dokument verschlüsselt, verschlüsselt man es immer auch für sich selbst. Auch wenn man nicht in PE-Keys steht. (Man kann sich nicht selbst aussperren)
6. Beim Zugriff über die LotusScript-API wird immer versucht, ein verschlüsseltes Dokument zu entschlüsseln
7. Beim Entschlüsseln wird immer auf das ID-File zurück gegriffen (hier sind die privaten schlüssel abgelegt) - es ist deshalb egal mit was für einer ID der Agent signiert ist.


Wegen 6. und 4. musst du dafür sorgen, dass dein LotusScript-Agent keinesfalls das Dokument entschlüsseln kann. D.h. niemals den Server in PE-Keys eintragen. (Sonst hat der Server ein Problem, wenn er das Dokument neu verschlüsseln muss, sobald ein Schlüssel fehlt, weil z.B. eine Person ausgeschieden ist) - 5. ist ebenfalls ein Sicherheitsproblem, da der Besitzer der ServerID fortan berechtigt ist, den Inhalt zu lesen.

Da das Kind meist schon in den Brunnen gefallen ist, und man i.d.R. sowieso nur nicht verschlüsselte Felder ändern will (siehe 1. und 3.) gibt es noch einen Trick:
- Formelagenten verwenden (meist keine Option)
- Mittels Evaluate & @SetDocField-Formel (klappt ganz gut, sofern man nur 'einfache' Werte schreiben möchte)

Funktion aus dem Stegreif getippt, nicht getestet!

Code

function setValue(doc as NotesDocument, name as String, value as Variant) 
  db = doc.parentDatabase()
  dim tmpDoc as new NotesDocument(db);
  tmpDoc.srcUnid = doc.universalId
  tmpDoc.name = name
  tmpDoc.value = value
  x = Evaluate("@SetDocField(srcUnid; name; value)", tmpDoc) ' setzt im Dokument mit der srcUnid das Feld 'name' auf den Wert 'value'
end function

Viel Erfolg
Roland

[Legolas]

Hallo pram,

danke erstmal für die ausführliche Rückmeldung.

Frage zu Punkt 4)
Wenn das so ist würde das ja bedeuten, dass es zu Problemen bei Feldern kommen würde, die mit mehreren ID's verschlüsselt sind (PublicEncryptionKeys).
Z.B.: Wenn einer der Mitarbeiter nicht mehr im NAB vorhanden ist.
Das kann ich mir ehrlich gesagt nicht vorstellen, dass sich Notes hier so verhält. Damit wäre ja jede Verschlüsselung ein potenzielles Risiko.

zu

Code

Da das Kind meist schon in den Brunnen gefallen ist, und man i.d.R. sowieso nur nicht verschlüsselte Felder ändern will (siehe 1. und 3.) gibt es noch einen Trick:

Leider ist es bei mir nicht so, ich muss die verschlüsselten Felder ändern. (Neue Berechtigungen hinzufügen, wenn z.B. neue Mitarbeiter eingestellt werden.)

Hast du hierzu noch eine Idee?


Grüße
Bernd

[pram]

Hallo Bernd,

Wenn das so ist würde das ja bedeuten, dass es zu Problemen bei Feldern kommen würde

Du meinst Dokumente? Dokumente werden verschlüsselt. Dabei werden alle Felder, die das SEAL bit gesetzt haben, verschlüsselt (mit den gleichen Schlüsseln) alle anderen nicht.

Die verschlüsselten Felder werden dann in das $SEAL Feld gepackt. Die Felder kann man nicht in Ansichten ausgeben und ich kann mir auch nicht vorstellen, dass sie als Leser oder Autorenfeld greifen.


Und ja, zum Entschlüsseln reicht ein Schlüssel, zum Verschlüsseln braucht man hingegen alle Schlüssel die in SE-  bzw. PE-Keys stehen.

Scheidet ein Mitarbeiter aus, hat man ein Problem (bzw. Person muss aus PE-Keys entfernt werden)
Hat man einen SE-Key nicht, muss man ihn sich von der Person zukommen lassen, die ihn erstellt hat oder aus SE-Keys entfernen.

Kommt man auf die Idee, sich einfach selbst einen SE-Key mit gleichem Namen zu erstellen, kann man das Dokument zwar verschlüsseln, bekommt aber später einen Support Call warum es der ursprüngliche Autor nicht mehr entschlüsseln kann, ob wohl es mit dem Namen von seinem SE-Key verschlüsselt wurde.

ich muss die verschlüsselten Felder ändern. (Neue Berechtigungen hinzufügen, wenn z.B. neue Mitarbeiter eingestellt werden.)

Erkläre mir das bitte. Sollte es sich um Leser-Felder handeln, kann ich mir nicht vorstellen, dass das funktioniert (der Dominoserver sieht die Felder ja nicht)

VG Roland

[Legolas]

Hallo pram,

ich versuch es mal zu erklären:

Ein Dokument hat ein Richtextfeld das verschlüsselt wird. (Eigenschaft: "Verschlüsselung für dieses Feld aktivieren" ist aktiviert  -> Rote Eingabefledkennzeichnung)
Der aktuelle Bearbeiter definiert über ein Namensfeld, welche Kollegen/Gruppen ebenfalls Zugriff auf das Feld haben sollen.
Beim Speichern des Dokuments werden dann die Gruppen aufgelöst und in das Notes Systemfeld "PublicEncryptionKeys" (in der Form Abbreviate) eingetragen.
Beim Speichern wird dann noch der Befehl call doc.encrypt aufgerufen. (Mus das überhaupt sein?)
Das wars.

Nun die Herausforderung:
Ändert sich nun die Mitglieder der im Dokument eigetragenen Gruppen, so muss die Berechtigung auf das Richtextfeld neu mit einem Backend Agenten (runonserver) gesetzte werden.
(Gruppen und Einträge die im Namensfeld stehen neu auflösen und in das Feld PublicEncryptionKeys eintragen.)

Anmerkung: Es werden keine Autoren und oder Reader Felder in der Form verwendet.
Alle Anwender dürfen das Dokument öffnen und alle Felder außer dem Richtextfeld sehen. (Das ist ja verschlüsselt und ist somit ausgeblendet. --> Außer sie sind im Namensfeld eingetragen und haben somit auch Zugirff auf das Richtextfeld.)

Ich hoffe das ist verständlich genug! 

Grüße
Bernd

[pram]

Nun die Herausforderung:
Ändert sich nun die Mitglieder der im Dokument eigetragenen Gruppen, so muss die Berechtigung auf das Richtextfeld neu mit einem Backend Agenten (runonserver) gesetzte werden.
(Gruppen und Einträge die im Namensfeld stehen neu auflösen und in das Feld PublicEncryptionKeys eintragen.)

Du willst also neu verschlüsseln - also die Verschlüsselung "aushebeln"

In unserer Anwendung, die Verschlüsselung verwendet, bedeutet: "Verschlüsseltes Dokument: höchste Vertrauensstufe"
Da ist es so, dass beim Speichern die Namen aufgelöst werden und der aktuelle Bediener sich im Klaren ist, dass er genau jetzt und für den angezeigten Personenkreis das Dokument verschlüsselt. Sollte sich die Gruppe ändern, wird das Dokument lediglich geflaggt, dass eine erneute Verschlüsselung erforderlich ist. Das Dokument muss dann von einer berechtigten Person geöffnet werden und neu gespeichert werden (auch dabei wird die Person in Kenntnis gesetzt, wer das Dokument jetzt entschlüsseln darf)
Eine Aktualisierung der Verschlüsselung durch den Server erfolgt bei uns nie, da dies ein Sicherheitsrisiko dar stellt, der Admin kann durch Ändern von Gruppen die Verschlüsselung ganz einfach aushebeln. Da ist es besser, man verwendet Lederfelder.

Genau das willst du aber in deinem Fall. D.h. der Server muss das Dokument entschlüsseln und wieder verschlüsseln können. Damit er es entschlüsseln kann, muss der Server mit in PE-Keys stehen, die Verschlüssselung würde in Deinem Fall auch funktionieren, da du die Gruppe (welche in einem anderen Feld steht) einfach aufläöst. Sicherheitstechnisch bringt dir das Ganze aber eher wenig. Da es mit wenig Aufwand von Admins umgangen werden kann.

Was spricht in deinem Anwendungsfall eigentlich gegen Leserfelder?

VG
Roland

[Andrew Harder]

Ich denke mal das Leserfelder nicht gewünscht sind, weil mehr Personen das Dokument sehen können sollen, aber nur ein eingeschränkter Kreis dieses eine Feld.
Da hätte ich genau das Gleiche gemacht wie Bernd es getan hat.

Gut die ServerID hätte ich wohl nicht hinzugefügt, aber das mit dem "SuperAdmin" hätte ich genau so gemacht.
Irgendwer muss ja die Leserechte haben, damit er da notfalls wieder was ändern kann.

Es geht jetzt nur noch darum, das ein Feld neu berechnet werden muss und ich gehe davon aus, das bereits das funktioniert.
Beim speichern meckert dann der Agent, das der Server das Dokument nicht entschlüsseln kann.

Jetzt ist die Server ID ja keine normale ID, daher meine Frage hierzu:
Läuft das Ganze ohne Fehler durch, wenn der "SuperAdmin" den Agenten - in der Agentenliste und mit Sicherheitsstufe 2 - von Hand startet?

[pram]

Ich denke mal das Leserfelder nicht gewünscht sind, weil mehr Personen das Dokument sehen können sollen, aber nur ein eingeschränkter Kreis dieses eine Feld.
Da hätte ich genau das Gleiche gemacht wie Bernd es getan hat.

ja, so gesehen macht das Sinn

Jetzt ist die Server ID ja keine normale ID, daher meine Frage hierzu:
Läuft das Ganze ohne Fehler durch, wenn der "SuperAdmin" den Agenten - in der Agentenliste und mit Sicherheitsstufe 2 - von Hand startet?

Ich denke, auf sowas wird es raus laufen. Wichtig: (aber ich denke das ist inzwischen schon rüber gekommen) - wenn der Agent periodisch ausgeführt werden soll, muss der Server drin stehen - ein Signieren des Ageneten mit einem anderen Benutzer funktioniert nicht (da der Schlüssel zum Entschlüsseln ja in der BenuterID gespeichert ist)

[Legolas]

Hallo Ihr Zwei,

mit Euren Vermutung habt ihr recht.

Starte ich den Agenten im User Kontext. 

Code

call agent.run()

funktioniert das Ganze.

Es gibt dann aber zwei große Einschränkungen:
1) Der Agent muss manuell gestartet werden.
2) Es werden natürlich nur die Dokumente aktualisiert, auf die der aktuelle User Zugriff hat.

Das ist zwar eine Lösungsmöglichkeit, die ist aber leider nicht sehr schön. Soweit ich das nun aber überblicken kann, wird es wohl keine andere Möglichkeit geben.

Grüße und Danke für die Unterstützung
Bernd

[pram]

2) Es werden natürlich nur die Dokumente aktualisiert, auf die der aktuelle User Zugriff hat.

Das wäre bei einem Serveragenten aber genau so. Du musst in eine Fall sicherstellen, dass der Server im Leserfeld ist, im anderen Fall, dass der SuperAdmin drin ist. (oder dem SuperAdmin ermöglichen, dass er in den Full Access Mode wechseln darf)

Das ist zwar eine Lösungsmöglichkeit, die ist aber leider nicht sehr schön. Soweit ich das nun aber überblicken kann, wird es wohl keine andere Möglichkeit geben.

Wie gesagt, könntest du den SuperAdmin durch die ServerID ersetzen, hast halt dann das Problem, dass du alle Dokumente neu verschlüsseln müsstest (was aber dein Agent schon kann *1).
Bedenke aber auch, dass Server einmal ersetzt werden oder auch der SuperAdmin aus dem Unternehmen ausscheidet.

Wäre es vielleicht möglich, für dein Vorhaben eine technische Notes-ID anzulegen. Der SuperAdmin der i. D. R. mit seiner persönlichen ID unterwegs ist, hätte dann keinen Zugriff und die Neuberechnung müsste er dann mit der technischen SuperAdmin ID erledigen.

*1) Falls du wirklich vor hast, die Verschlüsselung vom jetzigen  SuperAdmin zu einer andere ID zu übertragen, beachte bitte Punkt 5 - der SuperAdmin wird das Dokument noch immer entschlüsseln können, wenn er der letzte war, der es verschlüsselt hat.

Beachte bitte auch, falls du weitere Backend-Agenten/Aktionen hast, dass du sicherstellst, dass diese unmittelbar vorm doc.save ein doc.encrypt aufrufen - sonst hinterlassen sie (wegen 6.) möglicherweise das Dokument in einem unverschlüsselten Zustand


Gruß Roland.