TEA - Encrypted autorization with protected password

One of the basic safety levels of a network connection is to authorise the client who is trying to connect  to the server. If the standard authentication process is used, there is no safety precautions at all, because all the information is transferred over the network in a non-encrypted format. We use a more secure authentication check system in all our products. The algorithm used is called TEA (The Tiny Encryption Algorithm), which is a simple, but very powerful encryption algorithm. The whole aim of the TEA process is to encrypt the password using a randomly generated number sent by the server. After this the password is sent by the client, but it is not possible to read it easily, because the whole encryption algorithm is 128 bits long. This text describes the compression and decompression process it self.

 
Page Contents - How does the TEA process work?
- The TEA encryption algorithm
- BASE64
- The TEA / Base64 system implementation
- The TEA autorisation calculator in  HTML / Javascript
- C+ + TEA implementation description
- The HW product list where TEA is implemented.

 

How does the TEA process work?

When communicating on a network, a desirable function is to verify a clients authenticity or the whole conections authenticity. You could easily use a system of static passwords and user names, but a big disadvantage to this solution is that all the user names and passwords are transferred over the network in a non-encrypted format, so there is a chance that this data could be read by an unauthorised user.

It is more secure using other methods. There is for instance a single-use password system. A password list is created where each password can only be used once, or you can create a password generator. Another way is to use one of the cryptography methods. 

All of our final products have a symetrical cryptography method implemented for connection verification. This kind of method is simple, but also very safe and powerfull. The server uses a method of shared secrecy for verification. This secrecy (a key and password) is not transferred over the network. The authorisation process works in the following way:

  • The Client requests a connection process
  • The Server sends the randomly generated 64 bit number to the Client  
  • After that the Client receives the number, it enciphers the received number using the key (shared secrecy) and sends the result back to the server.
  • The Server receives the answer and using the number, which was sent to the client before, it deciphers the received Client's result and compares the password with its own one. If the password is correct, communication can proceed. If not, the connection is terminated from the server side.
     

The encryption key is 128 bits. Due to the key width, there is no possible way to scan for so many answer/responce couples needed for the key recognition. The key could be deciphered only if one of the HW devices where to be stolen. In this occurence, we recommend that you change the default password when the device is running in setup.

The Algorithm could be compromised, as with any other security precaution , by using obvious passwords, like "ghost" or "my wife's name".


The TEA Encryption algorithm

Our devices use the TEA algorithm, which can be characterised in the following way:

  • TEA is an abbreviation of,The Tiny Encryption Algorithm“, developed by David Wheeler and Roger Needham in the Computer laboratories of Cambridge University.
  • TEA is an easy and succint algorithm, but safe and powerful too.  
  • TEA is a block cipher, it uses 64 bit blocks encrypted by the 128 bit key.
  • TEA is a symetric cipher, which means, the same key is used for crypting and encrypting.  
  • TEA is one of the Feistel family algorithm (sometimes called DES-like) using non-descructive operations, XOR and ADD in the TEA's case.  
  • TEA is an iteration cipher, which means that the whole algorithm is divided into more than one part and processed one by one. Each step is processed by the same transformation.  

The Feistel transformation devides the data into two parts. Each part is processed by the specific function and XOR'd together with the second part. The whole algorithm is complemented with the constant ADD operation. The Server uses the non-encrypted text->encrypted text way. Its the same situation on the Client side.

Lets look at the process example, which was excluded from the client verification program. The program was written in JavaScript:

function encipher(str)
{
var sum = 0;
var delta = 0x9E3779B9;
var n = 32;
var s = base64Decode(str);
var y = s.charCodeAt(3)+ (s.charCodeAt(2) << 8) + (s.charCodeAt(1) << 16) + (s.charCodeAt(0) << 24);
var z = s.charCodeAt(7)+ (s.charCodeAt(6) << 8) + (s.charCodeAt(5) << 16) + (s.charCodeAt(4) << 24);
var w;
if(str.length != 12) {
return "Missing character";
} else if((
(s.charCodeAt(0) + s.charCodeAt(1) + s.charCodeAt(2) +
s.charCodeAt(3) + s.charCodeAt(4) + s.charCodeAt(5) +
s.charCodeAt(6) + s.charCodeAt(7) + s.charCodeAt(8))
& 0xFF) != 0)
{
return "Checksum Error";
} else {
while (n-- > 0) {
sum += delta
y += (((z << 4) + keyA) ^ (z + sum) ^ (((z >> 5) & 0x07FFFFFF) + keyB))
z += (((y << 4) + keyC) ^ (y + sum) ^ (((y >> 5) & 0x07FFFFFF) + keyD))
}
w = (y>>24 & 0xFF) + (y>>16 & 0xFF) + (y>>8 & 0xFF) + (y & 0xFF) +
(z>>24 & 0xFF) + (z>>16 & 0xFF) + (z>>8 & 0xFF) + (z & 0xFF);
w &= 0xFF;
w = 0x100 - w;
s = (String.fromCharCode(y>>24 & 0xFF, y>>16 & 0xFF, y>>8 & 0xFF, y & 0xFF) +
String.fromCharCode(z>>24 & 0xFF, z>>16 & 0xFF, z>>8 & 0xFF, z & 0xFF) +
String.fromCharCode(w & 0xFF));
return base64Encode(s);
}
}

The TEA Padlock Logo is copyright © David A. G. Gillies 1995-1998. All rights reserved.

Looking at the first lines, we find that the data sent after encryption to the server and received back are not in 64 bit format, but in 72 bit instead. They are transferred as a 12 character string. So how does it really work?

The Server sends the request in the 12 character string format in the BASE64 coding. This string is converted to 72bit format by the base64Decode() function. This binary number contains the data in the first 64 bit. The rest of the data is the check sum information. The data part is encrypted after which the check sum check is proceeded by the following loop:

while (n-- > 0) {
sum += delta
y += (((z << 4) + keyA) ^ (z + sum) ^ (((z >> 5) & 0x07FFFFFF) + keyB))
z += (((y << 4) + keyC) ^ (y + sum) ^ (((y >> 5) & 0x07FFFFFF) + keyD))
}

As we mentioned before, Tea is an iteration cipher, the encription loop is preceeded 32 times before it ends. The data is split into two parts (x,y), each part contains 32bits of information. Also the key is devided to four parts, each part also contains 32 bits (keyA, keyB, keyC, keyD).

The encrypted 64 bit data is supplemented by the check sum to the 72 bit format and after that they are converted to the 12 character string using a Base64 algorithm. This result is finally sent to the network.


BASE64

For the Binary data/printable string conversion, there are several usable methods. One of the most frequently used is the Base64 algorithm described in the RCF1341 standard. Base64 is sometimes called Radix64 coding, because it uses the 4 byte transformation system to four "6 bit" characters. These characters are transformed to a printable form using a special translation table.

The BASE64 coding system uses the following table:

code_table[0..63] = "ABCD...XYZabcd...xyz0123...789+/"

As a Base64 algorithm demonstration, lets have a look at the following code, written by Robert Graham in JavaScript. The same code was used in the whole TEA implementation as shown before. This described version been slightly altered for better understanding:

function base64ToAscii(c)
{
var result = 0;
if (0 <= c && c <= 25) { result = String.fromCharCode(c + 65); } // 65 = 'A'
else if (26 <= c && c <= 51) { result = String.fromCharCode(c - 26 + 97); } // 97 = 'a'
else if (52 <= c && c <= 61) { result = String.fromCharCode(c - 52 + 48); } // 48 = '0'
else if (c == 62) { result = '+'; }
else if( c == 63 ){ result = '/'; }
else { result = '='; }
return result;
}

The base64ToAscii function converts the 6 bit BASE64 binary data representation to the printable format.

function base64Encode(str)
{
var result = "";
var i = 0;
var sextet = 0;
var leftovers = 0;
var octet = 0;
for (i=0; i < str.length; i++) {
octet = str.charCodeAt(i);
switch( i % 3 ) {
case 0:
sextet = ( octet & 0xFC ) >> 2 ;
leftovers = octet & 0x03 ;
break;
case 1:
sextet = ( leftovers << 4 ) | ( ( octet & 0xF0 ) >> 4 );
leftovers = octet & 0x0F ;
break;
case 2:
sextet = ( leftovers << 2 ) | ( ( octet & 0xC0 ) >> 6 ) ;
leftovers = ( octet & 0x3F ) ;
break;
}
result = result + base64ToAscii(sextet);
if( (i % 3) == 2 ) result = result + base64ToAscii(leftovers);
}
return result.toString();
}

Base64 JavaScript implementation: Copyright © 2000 by Robert Graham (RobertGraham.com)

The base64Encode function is a little bit more complex. Depending on mod 3 it converts each three bytes to the BASE64 representation. This function doesn't take care of the right string length cutting.

The TEA/BASE64 algorithm in system implementation

The whole algorithm implementation, described before, is devided into 5 final modules, which are used by our devices:
  • Base64encode - Converting three bytes to four characters in Base64 representation.
  • Base64decode - Converting four characters in Base64 format to three byte representation.
  • TEAcommon - Some arithmetic functions and procedures, which were optimised for the TEAencipher and  TEAdecipher modules.
  • TEAencipher - Ciphers the text into 64bit variables called "salt" using the key.
  • TEAdecipher - Deciphers the text into 64bits variables called "salt" using the key.

These functions, together with the radn8 function (generating an eight byte random number), uses the telnet/auth function variant, which is the process the module uses to authorise the TCP data connection from/to the serial link. The authorisation of the telnet version uses the 8 byte randomly generated number principal, where the check sum was added and whole 12 character set in Base64 coding is sent to the network. These 12 characters are sent precisely after the connection is established. As an answer, there is a request for a response, which is created by ciphering the sent 8 byte random number using the key in the Base64 format.

Lets have a look at the situation closer. There is a Client Telnet connection displayed below (Win98, Teraterm Pro - IP 192.168.0.11) between the PC and our device in the Server Telnet 2 Serial mode (IP 192.168.0.8) and TEA switched on. The Win98 system checks the MAC address of the server first and than using a standard TCP handshake opens the connection:

arp who-has 192.168.0.8 tell 192.168.0.11
arp reply 192.168.0.8 is-at 0:0:e8:ee:10:35
192.168.0.11.2041 > 192.168.0.8.23: S
192.168.0.8.23 > 192.168.0.11.2041: S ack
192.168.0.11.2041 > 192.168.0.8.23: . ack 1

After the TCP/IP connection is opened correctly, the server checks the clients authenticity using the described mechanism. The server sends the randomly generated number in Base64 format as a "salt" to the client to check if they know the correct key or password.

192.168.0.8.23 > 192.168.0.11.2041: P 1:13(12) ack 1
706c 4657 3359 6750 6f79 7478 "plFW3YgPoytx"

The connection is established, usualy just before the response is sent. The Client sends the connection parameters using the Network Virtual Terminal mechanism (if the server has the NVT command support switched on, otherwise the NVT commands are taken as a valid response and the Client is not authorised).

192.168.0.11.2041 > 192.168.0.8.23: P 1:16(15) ack 13
fffb 18 <WILL TERMINAL TYPE>
fffd 03 <DO SUPPRESS GO AHEAD>
fffb 03 <WILL SUPPRESS GO AHEAD>
fffd 01 <DO ECHO>
fffb 1f <WILL NAWS>
192.168.0.8.23 > 192.168.0.11.2041: . ack 16

The user has moved the data from the terminal window to the Authorisation Calculator using a standard copy/paste edit function. In the case that check sum is not valid, the connection is closed. In our case, the responce was OK. You can recognise this by the Ack sign received from the Server. Finally the connection is processed in the standard way.

192.168.0.11.2041 > 192.168.0.8.23: P 16:28(12) ack 13
346b 6438 7852 4743 7734 6934 "4kd8xRGCw4i4"
192.168.0.8.23 > 192.168.0.11.2041: . ack 28

The TEA authorization calculator in HTML / Javascript

The following HTML page code shows how to calculate the TEA authorization using JavaScript:

 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>WEB51 autorization</title>
</head>
<body>
<h1>WEB51 autorization</h1>
<!-- last change 2002-AUG-1 -->
<!-- hhmts start -->
<SCRIPT><!--
/*
Base64
JavaScript implementation: Copyright (c) 2000 by Robert Graham (RobertGraham.com)
Tiny Encryption Algorithm
Algorithm: David Wheeler, Roger Needham, Cambridge University
www.ftp.cl.cam.ac.uk/ftp/papers/djw-rmn/djw-rmn-tea.html
JavaScript implementation: Radek Benedikt (benedikt@lphard.cz)
*/

// BEGIN of KEY
// in the next 4 lines is hardwired TEA key

var keyA = 0x01020304; //key 0.. 3
var keyB = 0x05060708; //key 4.. 7
var keyC = 0x090A0B0C; //key 8..11
var keyD = 0x0D0E0F10; //key 12..15

// END of KEY

function base64ToAscii(c)
{
var result = 0;
if (0 <= c && c <= 25) { result = String.fromCharCode(c + 65); } // 65 = 'A'
else if (26 <= c && c <= 51) { result = String.fromCharCode(c - 26 + 97); } // 97 = 'a'
else if (52 <= c && c <= 61) { result = String.fromCharCode(c - 52 + 48); } // 48 = '0'
else if (c == 62) { result = '+'; }
else if( c == 63 ){ result = '/'; }
else { result = '='; }
return result;
}

function base64Decode(str)
{
var result = "";
var i = 0;
var x = 0;
var y = 0;
var z = 0;
var count = -1;
for (i=0; i < str.length; i++) {
c = str.charAt(i);
if ('A' <= c && c <= 'Z') x = str.charCodeAt(i) - 65; // 65 = 'A'
else if ('a' <= c && c <= 'z') x = str.charCodeAt(i) - 97 + 26; // 97 = 'a'
else if ('0' <= c && c <= '9') x = str.charCodeAt(i) - 48 + 52; // 48 = '0'
else if (c == '+') x = 62;
else if (c == '/') x = 63;
else continue;
count++;
switch (count % 4) {
case 0:
y = x;
continue;
case 1:
z = (y << 2) | (x >> 4);
y = x & 0x0F;
break;
case 2:
z = (y << 4) | (x >> 2);
y = x & 0x03;
break;
case 3:
z = (y << 6) | x;
y = 0;
break;
}
result = result + String.fromCharCode(z);
}
return result.toString();
}

function base64Encode(str)
{
var result = "";
var i = 0;
var sextet = 0;
var leftovers = 0;
var octet = 0;
for (i=0; i < str.length; i++) {
octet = str.charCodeAt(i);
switch( i % 3 ) {
case 0:
sextet = ( octet & 0xFC ) >> 2 ;
leftovers = octet & 0x03 ;
break;
case 1:
sextet = ( leftovers << 4 ) | ( ( octet & 0xF0 ) >> 4 );
leftovers = octet & 0x0F ;
break;
case 2:
sextet = ( leftovers << 2 ) | ( ( octet & 0xC0 ) >> 6 ) ;
leftovers = ( octet & 0x3F ) ;
break;
}
result = result + base64ToAscii(sextet);
if( (i % 3) == 2 ) result = result + base64ToAscii(leftovers);
}
return result.toString();
}

function encipher(str)
{
var sum = 0;
var delta = 0x9E3779B9;
var n = 32;
var s = base64Decode(str);
var y = s.charCodeAt(3)+ (s.charCodeAt(2) << 8) + (s.charCodeAt(1) << 16) + (s.charCodeAt(0) << 24);
var z = s.charCodeAt(7)+ (s.charCodeAt(6) << 8) + (s.charCodeAt(5) << 16) + (s.charCodeAt(4) << 24);
var w;
if(str.length != 12) {
return "Missing character";
} else if((
(s.charCodeAt(0) + s.charCodeAt(1) + s.charCodeAt(2) +
s.charCodeAt(3) + s.charCodeAt(4) + s.charCodeAt(5) +
s.charCodeAt(6) + s.charCodeAt(7) + s.charCodeAt(8))
& 0xFF) != 0)
{
return "Checksum Error";
} else {
while (n-- > 0) {
sum += delta
y += (((z << 4) + keyA) ^ (z + sum) ^ (((z >> 5) & 0x07FFFFFF) + keyB))
z += (((y << 4) + keyC) ^ (y + sum) ^ (((y >> 5) & 0x07FFFFFF) + keyD))
}
w = (y>>24 & 0xFF) + (y>>16 & 0xFF) + (y>>8 & 0xFF) + (y & 0xFF) +
(z>>24 & 0xFF) + (z>>16 & 0xFF) + (z>>8 & 0xFF) + (z & 0xFF);
w &= 0xFF;
w = 0x100 - w;
s = (String.fromCharCode(y>>24 & 0xFF, y>>16 & 0xFF, y>>8 & 0xFF, y & 0xFF) +
String.fromCharCode(z>>24 & 0xFF, z>>16 & 0xFF, z>>8 & 0xFF, z & 0xFF) +
String.fromCharCode(w & 0xFF));
return base64Encode(s);
}
}

//-->
</SCRIPT>
<FORM name=myForm>
<INPUT type=text name=text1 size=16></INPUT>
<INPUT name=button1 onclick="this.form.text1.value=encipher(this.form.text1.value)" type=button value=Reply>
</FORM>
<!-- hhmts end -->
</body>
</html>

The TEA calculator written in C++ language description.

You can use the following C++ algorithm for the TEA programming, which enables you to use the TEA function together with our HW products:

void __fastcall TForm1::BtnTEAStartClick(TObject *Sender)
{
AnsiString PomStr;
unsigned char InBuf[64], OutBuf[65];
unsigned long y,z;
unsigned char CheckSum;
// Nastaveni klice
PomStr = "0x" + EKey1 -> Text;
TEAa = StrToInt(PomStr);
PomStr = "0x" + EKey2 -> Text;
TEAb = StrToInt(PomStr);
PomStr = "0x" + EKey3 -> Text;
TEAc = StrToInt(PomStr);
PomStr = "0x" + EKey4 -> Text;
TEAd = StrToInt(PomStr);


// Reading and decoding the input string („ salt “)
strcpy(InBuf, AutEdit -> Text.c_str());
base64Decode(InBuf, OutBuf, 12);
// Checking up the check sum
CheckSum = OutBuf[0];
for (int i = 1; i < 9; i++)
CheckSum = CheckSum + OutBuf[i];
if (CheckSum)
{
AutEdit -> Text = " CRC Error of the input string ";
return;
} // The „ salt “ encryption


y=z=0;
preparekey(&y, &z, OutBuf+0);
updatekey(&y, &z, OutBuf+0);
// The check sum cointing routine
CheckSum = 0;
for (int i = 0; i < 8; i++)
CheckSum = CheckSum + OutBuf[i];
OutBuf[8] = 256 - CheckSum;
OutBuf[9] = NULL;
// The output string codding by the Base64
base64Encode(OutBuf, InBuf, 9);
// There is a prepared output string in InBuf , so why do not to send it back?
ClientSocket1 -> Socket -> SendBuf(InBuf, 12);
}

There is a key transferred from the EDIT boxes EKey1 up to EKey4 to the TEAa upto TEAd variables at the beginning. In the EDIT box called AutEdit, there is a "salt" sent by the server, which is transferred to binary data into a OutBuf variable by the base64Decode() function. In the following cycle, there is a check sum check. If the check sum is clear, the program creates the data encryption. The preparekey() function makes the y and z variables calculation and than the updatekey() function ciphers the data. After that, the 9th byte is added as a chack sum. Finaly the base64Encode() function codes the data in OutBuf to the InBuf variable and the result is sent back to the server.

 

Download

 
 

Related products

These products use the TEA algorithm. If you are interested in all of our products, please check our Product page.
  • PortBox - Ethernet / RS-232/485/422 converter
    Conversion of a serial line to Ethernet and vice versa (Server or Client/Server mode) with RS-485 support and protocol enhancements. Data is transmitted over the Ethernet using the TCP/IP or UDP/IP protocols.
     
  • HW Virtual Serial Port - create Com5 and redirect it over the TCP/IP
    The Virtual Serial Port driver for Windows is a software tool, which adds a virtual Comm port to the system, for instance COM5, and all the data from this port is re-directed to another TCP/IP device on the Ethernet network.
    This software is free for any device, but with non HWgroup device's there are baudrate limitations upto 14,400 Bd.
     
  • Eth. I/O Controller - Remote binary I/O pins control + RS-232 converter
    Conversion of a serial line to Ethernet and vice versa (Server or Client/Server mode) with RS-485 support and protocol enhancements. Data is transmitted over the Ethernet using the TCP/IP or UDP/IP protocols.
     
  • Charon I module - low-cost embedded interface module converter
    The fabulous Charon, from Roman mythology, was the boatman on the river Styx, which separated the world of the living and the world of the dead. His boat was the only "interface" crossing that boundary. Our Charon I module is named after him because it is also an interface. Typically, it converts Ethernet to RS232 or RS485 and vice versa. However, it can also be used as a WWW server, control inputs and outputs, and so on, utilizing either our ready-made firmware or your custom created software.