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:
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
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:
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?
doc.encryptionKeys = "[your shared key]"
doc.publicEncryptionKeys = "[target user list]"
Call doc.encrypt
Call doc.removeItem("sharedEncryptionKeys")
Call doc.save (whatever)
Grüße
Bernd
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!
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
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
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