RC4-Verschlüsselung mit Salts //RC4 encryption with salts

Zum Verschlüsseln von Formularen gibt es bei Adobe schon diverse Möglichkeiten, die auch sehr sicher sind.
Aber, mit all den erforderlichen Zertifkaten und Digitalen ID's ist das alles irgenwie auch zu kompliziert und eben auch teuer.
Unternehmen mögen das in Kauf nehmen. Aber der kleine Mann?

Also ist wieder Selbermachen angesagt.
Dieses Beispiel zeigt ein Formular mit mehreren Feldern die alle in einem Rutsch mittels RC4-Algorithmus und eines Passwortes verschlüsselt werden können.
Nun wäre das mit einem Klartext-Passwort ja nicht sonderlich sicher, daher wird das Ganze mit ordentlich vielen Skripten verschleiert, aber der Reihe nach.

Um das Klartext-Passwort unleserlich zu machen, wird dieses durch verschiedene Hash-Algorithmen (MD4, MD5 und SHA-512) geschickt.
Gestärkt wird dieser Vorgang durch das sogenannte Salting.
Hierbei wird der erzeugte Hashwert mit einem weiteren, beliebigen Hashwerte aus einer  Liste mit hunderten anderer Hashwerte verändert und dann nochmal gehasht.
Die Liste mit den Hashwerten wird erst bei Bedarf erzeugt, muss also nicht schon vorab in das Formular geskriptet werden.
Die Technik dafür hat John Brinkman kürzlich in seinem Blog beschrieben.
Sie verwendet das Extras-Objekt, das das Erstellen, Speichern und Löschen von Werten zur Laufzeit erlaubt.
Eine unglaublich nützliche Sache das!

Nachdem der finale Hashwert erstellt wurde, wird dieser zusammen mit dem RC4-Algorithmus eingesetzt, um die Werte alle Formularfelder zum verschlüsseln.

Damit die Daten auch wieder entschlüsselt werden können, wird das gehashte Passwort gespeichert, nicht aber der finale Hashwert, der wird erst wieder berechnet und mit dem Hashwert der Benutzereingabe verglichen.
Stimmt dieser überein werden alle Felder wieder entschlüsselt und die Liste mit den Hashwerten verworfen, da sie nicht mehr gebraucht wird.

Beim nächsten Verschlüsseln wird die Hash-Liste komplett neu erstellt.
Da dafür ein Zeitstempel verwendet wird, sind die Hashwerte der Liste jedes mal anders, was die Liste relativ einzigartig macht.
Dadurch werden auch die Daten immer anders verschlüsselt, auch wenn immer dasselbe Passwort verwendet wird.

Adobe already offers methods to encrypt forms, which are surely secure.
But, with all those certifactes and digital ID's this is even complicated and expensive.
This possibly is not problem for companies. But for the regular people, isn't it?

So, Do-It-Yourself is the order of the day.
This example shows a form with several form fields which are encrypted through the RC4-algorithm and a password in one go.
Well, in this scenario a cleartext-password wouldn't be very secure, so we use several scripts to make it stronger and securer.
But one by one.

To make the cleartext password unreadable it passes different hash-algorithms (MD4, MD5 and SHA-512).
It also get's strenghtened by the so called Salting.
Thereby the hash is combined with another, arbitraty hash from a list with hundreds of hashed
before it is hashed once again.
The hash list is only generated as needed, so it's not neccessary to script it already into the form before.
A technique to do this was described by John Brinkman only recently in his Blog.
It uses the extras object which allows the creation, storage and deletion of values at runtime.
An incredible useful thing!

After the final hash was created it's used together with RC4 to encrypt the form fields.

To be able to decrypt the fields later, the hashed keyword is stored but not the final hash.
It will be created again in front of the decryption and checked against the hashed users input.
If they match the fields get decrypted and the hash list is deleted, because it is no longer needed.

Only during the next encryption the hash list is generated again.
Because there is a time stamp used, the hashes in the list are always totally different which make the list relatively unique.
So the encrypted data will allway look different, even if the same keyword is used again and again.


Ver-/Entschlüsselung aller Formularfelder
//
En-/Decryption of all form fields

Beispiel-Formular
//
Example form
https://workspaces.acrobat.com/app.html#d=tdqsAP*XogjhpJO4aZZ5Wg

Ausnahmeregelungen für Gesicherten Modus von Adobe Reader X erstellen//Create custom policies for Protected Mode of Adobe Reader X

So, Adobe hat's vollbracht und die neue Version 10 (alias X) von Acrobat und Reader veröffentlicht.
Einher gehen etliche Verbesserungen, vorallem die Sicherheit betreffend.

Der kostenlose Adobe Reader, der immerhin schon über 650 Millionen Mal geladen wurde, wurde ganz besonders verbessert.
Der sogenannte "Geschütze Modus" lässt den Prozess des Readers in einer Sandbox laufen, sodass PDF-Dateien ohne Weiteres keinen Zugriff mehr auf das Dateisystem bekommen, und somit auch bösartige Inhalte wie eingebetteter Shell-Code keinen Schaden mehr anrichten können.
Ich kann nur jedem empfehlen den Reader immer im Geschützen Modus zu verwenden!

Aber das Ganze hat auch Nebenwirkungen, die sich auf Workflows auswirken können, die auf Folder-Level-Skripte basieren, denn auch diese werden wirkungsvoll durch die Sandbox geblockt.

Ich hatte in einem früheren Beispiel mal beschrieben, wie sich XFA-Formulare mit einem Folder-Level-Skript in bestimmte Verzeichnisse speichern lassen.
Dies ist so ein Workflow, der nicht mehr funktioniert, wenn der "Geschützte Modus" aktiv ist.

Wenn Sie das Formular im Reader X mit aktiviertem Geschützem Modus testen, werden Sie nur einen Ausnahmefehler in der Konsole sehen.

NotAllowedError: Sicherheitseinstellungen verhindern den Zugriff auf diese Eigenschaft oder Methode.

Um diesen Workflow wieder gängig zu bekommen ohne auf die Sicherheit des Geschützen Modus zu verzichten, gibt es die Möglichkeit Ausnahmeregelungen in einer Whitelist für den Geschützen Modus zu definieren.

Die Einrichtung dieser Whitelist erfolgt in 2 Schritten.
Zuerst müssen Sie in der Registry einen neuen DWORD-Wert anlegen, damit Reader X überhaupt die Erlaubnis hat, die Whitelist zu verwenden.
Danach definieren Sie die Ausnahmeregelungen in der Whitelist selbst.

Well, Adobe has done it and released the generation 10 (alias X) of Acrobat and Reader. This generations brings a lot of enhancements.

Especially the free Adobe Reader, that already has been downloaded over 650 million times, was improved.
The so called "Protected Mode" runs the Reader process in a sandbox, so PDF files do not get access to the file system.
As a result malicious contents as embedded shell codes cannot harm the system.
I only can advise to use Reader always with the Protected Mode activated.

But, the also will have side effects to workflows that are working with folder level scripts, cause those script will also be blocked by the sandbox mechnism.

I an earlier example I had described, how to use folder level scripts to save XFA-forms into specific directories.
This is such a workflow that won't work with the "Protected Mode" activated.

If you use this example in Reader X with the Protected Mode activated, you will only see an exception in the console.

NotAllowedError: Security settings prevent access to this property or method.

To make it work again without deactivating the security of the Protected Mode, you can describe policies for the Protected Mode in a white list.

The setup of the white list has two steps.
You first have to create a new DWORD value in the registry to allow Reader X the usage of a whitelist.
Then you define the policies in the white list.

Ausnahmefehler in Reader X // Exception in Reader X

Schritt für Schritt // Step  by Step

Öffnen Sie den Registrierungs-Editor und suchen Sie den Verzeichniseintrag:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\10.0\FeatureLockDown

Erstellen Sie hier einen neuen DWORD-Wert namens bUseWhitelistConfigFile und weisen Sie diesem den Wert 1 zu.

Open the registry editor and look for the entry:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\10.0\FeatureLockDown

Create a new DWORD-value named bUseWhitelistConfigFile with the value 1.

Öffnen Sie den Programmorder von Adobe Reader X z.B. unter C:\Programme (x86)\Adobe\Reader 10.0\Reader\.

In dem Ordner muss sich die AcroRdr32.exe befinden, andernfalls funktioniert die Whitelist nicht!

Erstellen Sie hier eine Textdatei namens ProtectedModeWhitelistConfig.txt.

Open the program folder of Adobe Reader X under C:\Program Files (x86)\Adobe\Reader 10.0\Reader\ for example.

The folder has to contain the AcroRdr32.exe otherwise the white list won't work!

Create a new text file and name it ProtectedModeWhitelistConfig.txt.

Whitelist im Programmordner // White list in the program folder

Öffnen Sie die Textdatei, um die Ausnahmeregelungen zu definieren.

Insgesamt gibt es 8 Regelarten, von denen für diesen Workflow nur eine interessant ist. 

Die anderen sind vor allem für Entwickler von Plug-Ins interessant, weshalb ich darauf nicht weiter eingehe.

Es können beliebig viele Regelungen eingetragen werden, aber immer nur eine pro Zeile.

Kommentare werden in eigene Zeile geschrieben und mit einem Semikolon am Zeilenanfang auskommentiert.

Sie können Platzhalter für die Regelungen verwenden.

* für beliebig viele Zeichen  – jeweils nur eins in Reihe erlaubt

? für ein bestimmtes Zeichen – mehrere in Reihe erlaubt
Desweiteren können Sie Umgebungsvariablen wie z.B. %user%, %temp% oder %systemroot% verwenden, um die relativen Pfade zu den Systemordner aufzulösen.

Beispielregelungen:

; Laufwerk c:\ freigeben

FILES_ALLOW_ANY = c:\*

; Ordner mit dem Namen "LCB" freigeben – unabhängig davon wo der Ordner gespeichert ist

FILES_ALLOW_ANY = *\LCB\*

; Ordner des angemeldeten Benutzers freigeben – wie z.B. C:\Benutzer\Benutzername\

FILES_ALLOW_ANY = %homedrive%%homepath%\*

; PDF-Dateien beginnend mit "LCB_SaveAs" erlauben – wie z.B. LCB_SaveAs_Beispiel.pdf

FILES_ALLOW_ANY = *\LCB_SaveAs*.pdf

; PDF-Dateien generell erlauben (Nicht empfohlen!)

FILES_ALLOW_ANY = *.pdf

Open the text file to define the policies.

There are 8 rule types available, but only one is interesting for this workflow.

The others are more interesting for developers of plug-ins, so I won't use them here.

You can define as many rule as you like, but only one per line.

Comments have to be written in separate lines and are commented out be a semi-colon at the beginning of the line.

You can use wildcards for your policies.

* for several characters – only one in series allowed

? for one charecter – several in series allowed
Also, you can use enviroment variables such as %user%, %temp% oder %systemroot%, to resolve the relative path to the system folders.

Example policies:

; Unblock drive c:\

FILES_ALLOW_ANY = c:\*

; Unblock the folder named "LCB" – no matter where the folder is stored 

FILES_ALLOW_ANY = *\LCB\*

; Unblock folder of current logged in user – like c:\user\username

FILES_ALLOW_ANY = %homedrive%%homepath%\*

; Unblock PDF files beginning with "LCB_SaveAs" – such as LCB_SaveAs_Example.pdf

FILES_ALLOW_ANY = *\LCB_SaveAs*.pdf

; Unblock all PDF files (not recommended!)

FILES_ALLOW_ANY = *.pdf

Eine Ausnahmeregelung in der Whitelist
//
A policy in the white list

Registrierungsdatei – zum Aktivieren der Whitelist für Adobe Reader X
//
Registry file – for activation of white list usage in Adobe Reader X
https://acrobat.com/#d=ssEHVn-3XANi7bbF9eZEVQ

Beispiel – Whitelist
//
Sample – white list
https://acrobat.com/#d=Z1HrB*ocHqklQX*w1bfiXg

Sichere Passwörter erstellen//Generate secure passwords

Passwörter sind wichtig für die Datensicherheit, doch den Menschen fällt es schwer sich sichere Passwörter auszudenken und vor allem zu merken.
Es nützt wenig wenn man ein 12-stelliges Password verwendet, dass in jedem Duden steht.
Aus diesem Grund können noch immer viele Benutzerkonten mit einfachen Bruteforce-Attacken geknackt werden.

Dieses Formular soll Ihnen ein wenig unter die Arme greifen.
Es erstellt aus beliebigen Eingaben kryptische Passwörter mit Groß- und Kleinschreibung, Ziffern, Buchstaben und Sonderzeichen und mit bis zu 64 Zeichen.
Das generierte Passwort können Sie dann einfach per Strg + C kopieren und in das jeweilige Anmeldefenster einfügen.
Sie brauchen sich eigentlich nur das merken, was sie in Klartext eingeben.

Die Passwörter werden mithilfe eines SHA512-Algorhytmus erstellt, der in einem Scriptobject steckt.
Ein verstecktes Formularobjekt "Trigger" stößt dann die Berechnungen an.

Passwords are very important for data security but for people it's often difficult to think out secure passwords and especially to remember them.
A twelwe-digit password is possibly useless if it is a word you can find in every spelling dictionary.
That's why many accounts are still easy to capture through simple brute-force attacks.

This form should help you a bit with this scenario.
From any input it generates cryptic passwords with upper and lower case characters, digits and special characters, and a length upto 64 digits.
You can copy (ctrl + c) the generated password and paste it directly into your login window.
Actualy all you need to remember is the cleartext.

The passwords are generated by a SHA512 algorithm that is put into a script object.
All calculations are triggered by a hidden form object "Trigger".

Passwort-Generator // Password Generator:

Skript für Trigger // Script for Trigger:

var Cleartext = Input.value.text.value;

var PW_Length = Password_Length.value.text.value;

var PW_Coding = Password_Coding.value.text.value;

var PW_String 

if(Cleartext.length >= 1)

{

if(PW_Coding == "BASE64")

{

PW_String = SHA512.b64_sha512(Cleartext);

}

if(PW_Coding == "HEX")

{

PW_String = SHA512.hex_sha512(Cleartext);

}

if(PW_Coding == "ANY")

{

PW_String = SHA512.any_sha512(Cleartext, Cleartext);

}

Output.rawValue = PW_String.substr(0, PW_Length);

xfa.host.setFocus("Output");

}

else

{

Output.rawValue = null;

}

Beispiel // Example:
https://workspaces.acrobat.com/app.html#d=dvPh1TeA9NC3VUK3zBp15g

Formulare mit RC4 verschlüsseln //Encrypt Forms with RC4

Basierend auf dem Beispiel Base64 Encryption habe ich ein anderes Beispiel entwickelt, das anstelle von Base64 den Rivest Cipher No.4 Algorythmus (RC4) verwendet.

Der Algorythmus arbeitet innerhalb XFA-Formularen zwar, benötigt aber zuvor etwas Feinschliff.
Damit es beim Verschlüsseln und Entschlüsseln nicht zur Fehler kommt, die dazu führen, dass der Text abgeschnitten wird oder bestimmte Schriftzeichen fehlerhaft verarbeitet werden, muss der eigentliche Algorithmus mit der escape() bzw. unescape() Funktion kombiniert werden.

Für einen möglichst hohen Verschlüsselungsgrad wird aus dem Password des Benutzers ein Hashwert generiert, der mit einem anderen Hashwert kombiniert wird, das sogenannte Salting.
Aus diesem wird dann wiederum ein Hashwert erzeugt, der letzlich zur Ver- und Entschlüsselung verwendet wird.

Based on the example for the Base64 Encryption I developed another example, that uses the Rivest Cipher No. 4 algorithm (RC4).

To work proper in XFA-forms the algorithm needs some final touch.
Otherwise it will produces errors like cuf off text and misinterpreted characters when encrypting oder decrypting the text strings.
Therefore I added the escape() repectively unescape() functions to the algorithm for the enryption and decryption.

For a high ciphering level the form generates a hash-key from the users password which then will be combined with another hash-key (the so-called Salting). From this salted hash-key there will be generated a final hash-key which is used for the en- and decryption.


JavaSript für Verschlüsselung // JavaScript for Encryption:

var CharSetSize = 256;

var RC4_SubstitutionBox = new Array(CharSetSize);


function RC4_crypt (KeyWord, InputTextString)
{
var i, j, k = 0;
var Temp = 0;
var t = 0;
var ModifiedText = "";


for (j = 0; j < CharSetSize; j++)
RC4_SubstitutionBox[j] = j;
j = 0;


for (i=0; i < CharSetSize; i++)
{
j = (j + RC4_SubstitutionBox[i] + KeyWord.charCodeAt(i % KeyWord.length)) % CharSetSize;
Temp = RC4_SubstitutionBox[i];
RC4_SubstitutionBox[i] = RC4_SubstitutionBox[j];
RC4_SubstitutionBox[j] = Temp;
}


for (k=0; k < InputTextString.length; k++)
{
i = (i + 1) % CharSetSize;
j = (j + RC4_SubstitutionBox[i]) % CharSetSize;
Temp = RC4_SubstitutionBox[i];
RC4_SubstitutionBox[i] = RC4_SubstitutionBox[j];
RC4_SubstitutionBox[j] = Temp;
t = (RC4_SubstitutionBox[i] + RC4_SubstitutionBox[j]) % CharSetSize;
ModifiedText = ModifiedText + String.fromCharCode(InputTextString.charCodeAt(k) ^ RC4_SubstitutionBox[t]);
}
return escape(ModifiedText);
}

Klartext // Cleartext:

RC4-verschlüsselter Text // RC4-Encrypted Text:

Beispiel // Example:
https://acrobat.com/#d=35uUne9Hl5V*fZG8ZRWLBA

Formulare mit Base64 verschlüsseln //Encrypt Forms with Base64

Haben Sie schon mal ein PDF-Formular gehabt, dessen Inhalt sie verschlüsseln können?
Ich auch nicht. Warum eigentlich nicht?
Es kann doch nur praktisch sein, die Inhalte einer PDF zu verschlüsseln anstatt die PDF als solche.
Schließlich gibt es mittlerweile diverse Tools, die die Passwortschale einer PDF in Sekunden knacken.

Also warum nicht die PDF offen lassen und den Inhalt unleserlich machen?

Dieses Beispiel-Formular verwendet ein Script zum Verschlüsseln der Daten als Base64-String.
Das Ganze wird durch eine Passwortabfrage gesichert, die Hashwerte aus den Eingaben erstellt und vergleicht.

Have you ever seen a PDF form where you could encrypt the contents?
I didn't, but why?
It will be so handy to encrypt the content instead of the whole file.
Because there are so many cracking tools around, that will break the password shell within seconds.

So why don't leave file open and make the contents unreadable?

The example form uses a script to encrypt the data as base64 string, protected by a password query that uses hashes and compares them.

Klartext
//
Cleartext:

Base64-verschlüsselter Text
//
Base64-encrypted Text:

Beispielformular
//
Sample form:
https://files.acrobat.com/a/preview/84c26bcc-68f0-43a3-b1e6-4f07c7dd5d6e