Record Key Access

Print this Page	4.4 Access 16. Authentication Control	Close this Page

4.4.16. Record Key Access:

Record keys need to be passed between functions using hackable methods such as URL. It is critical that keys cannot be changed in any way or any change will be detected and the criminal blacklisted.

Reality:

The methods published in this page are typical for guidance purposes, but in reality, the methods are many times more complex. Layer after layer of obfuscation has been added in a continual series of improvements that will continue to become more complex. The number of layers appears to be the trade secret - a criminal may be able to crack one level of obfuscation, but the result is just a string of numbers.

Based on factors such as day number, week number and day of month, algorithms change, scramble orders change and CRC cell sizes change. The result is a means to pass record keys in links that may be hacked from time to time, but every hacking attempt will be detected. The integrity of the envelope-letter method of electronic communication is founded on this key security design.

Protection:

Rather than just use a key on its own, it is married with a number of other immutable field values to create composite that cannot be guessed. The starting point is that the record key is married to the authors key, authored date and authored time. It becomes more of a challenge for a criminal to guess another record key with its exact authors key date and time.

Composite:

Keys are 8 digit integers. Date and time are 8 digit integers. The concatenation of record key, author key, date and time is 4*8 as 32 digits.

On its own, this 32 digit URL would be hard to guess, but given time, brute force will guess the correct date and time.

Extension:

The business requirement it to make it more of a challenge to be able to guess the date and time when a record was created. This begins by scrambling to 32 digits so the criminal has to guess where the date and time are stored. It continues with CRC check digits being appended so any invalid guess can instantly be detected and stopped.

Compression:

The resulting digital string has selected large numbers replaced with alpha letters. For example; "1001" may exist many times and each instance will be replaced with "a".

Eliza:

Eliza manages (1) the creation procedure and (2) the validation procedure. Creation begins with 5 parameters and returns an alpha-numeric string that is safe to use in a URL. Validation begins with an alpha-numeric string and returns the validated 5 parameters or error message.

The objective is to ensure that hacking is not practical, even by a big agency or resourceful criminal. And an objective is to use methods that are not processor intensive - compound obfuscation has exponentially high costs to crack.

Predictability:

So much data in the URL has a very predictable range of values.

. Year is 2016 for every email created in 2016.

. Month is only 01 to 12 fixed for a month and then all changes on the first of next month.

. Day is only 01 to 31 so easy to detect when the month changes.

. Hour is only 00 to 23 but 09 to 17 have a very high usage.

. Minute is only 00 to 59.

. Second is only 00 to 59.

. Key is 001000001 to 00100123 slowly increasing in a predictable way.

By simply monitoring the range of values for a few hundred samples, the likely field can be guessed. By any definition, this is not good enough. The Unix time stamp number is a more effective solution = the number of seconds since 1 Jan 1970 as 10 digits minus 12345678 and reversed.

Create Procedure:

1. Parameters provided are page number, record key, author key, authored date and authored time.

2. Each parameter is reversed and appended into a known order of 36 digits.

3. Fragment into 6 cells of 7 digit numbers - last cell has 1 digit.

4. CRC7 is calculated on each cell, reversed and appended as 7th cell.

5. Scramble cell order and create string of 43 digits.

6. Fragment into 9 cells of 5 digit numbers - last cell has 3 digits.

7. CRC5 is calculated on each cell, reversed and appended as 10th cell.

8. Scramble cell order and create string of 48 digits.

9. Replace selected number strings with 52 alpha upper and lower case letters.

Validation:

1. Replace alpha codes with applicable digits.

2. Fragment 48 digits into 10 cells of 5 digits.

3. Unscramble cell order and extract CRC cell.

4. Calculate CRC5 on remaining cells and return error is not the same as the CRC cell.

5. Assemble 43 digit string from remaining cells.

6. Fragments into 7 cells of 7 digits.

7. Unscramble cell order and extract CRC cell.

8. Calculate CRC7 on remaining cells and return error is not the same as the CRC cell.

9. Assemble 36 digit string from remaining cells.

10. Extract each parameter from 36 digit string in known order.

11. Reverse the order of each parameter.

Version 80:

Tests show that 50 digits are barely good enough - 80 is better but 300 to 400 are needed when only numbers are used. CRC scramble rules for 10, 8 and 5 digits have reasonable results.

It is now clear that the FBI are not able to crack a normal 2048 bit key = 256 bytes (base 8). A URL can only hold base 7 codes that can be approximated to AZaz01 as 62 characters plus 2 more as 64 - we need 300 to 400 codes to be like a key. Each date and time pair of digits has its own unique alpha-numberic randomized lookup table that is salted.

Integer key to alpha-numeric needs a special randomising method that does not need to be reversable - the method includes divisor remainders.

ZEMA immutable fields include: 01, 03, 15, 16, 20, 21, 22. Each field is an integer that may be assumed to be 8 digits, but more reasonably may be a variable AN string.

Version 92:

The method has been extended to be 92 digits that are shortened by variable AN replacement.

Special:

The use of included or special functions has turned to favour specials that must be declared and approved by WPG.

Every special must have a 52 digit URL that is CRC checked before checking the special link URL.