The Hardware Side of Cryptography

8 June 2013

PONDOH : A simple voice chat application

Filed under: Uncategorized — edipermadi @ 1:00 am

During my trip from office to house, i was thinking of a simple “linux based” secure voice call software. Let say when A and B wants to talk each other using virtually private communication line over the net. The software is entirely built out of open source libraries such as voice compression library (Speex), Multi precision math (GNU multi precision library), packetizer (OGG) and Audio interface library (Jack) and Python GTK as its UI. The ciphering side would be done using AES 256.

Here is the big picture, 2 clients connected each other through server


The block diagram of each client.


Finally, this is prototype the binding and call initiating scheme.

Client A and B Setup:

1. Client A open connection to server S
2. Server S accepts connection from client A
3. Client A sends BIND PDU that contents its own user_id, say user_id_A
4. Server S returns RSA_8192((random_A | random | key_expiration | transport_key_A), public_key[user_id_A])
5. Client A sends AES_256(RSA_8192((random_A | random | password_A), private_key_A), transport_key_A)
6. Server S verifies (that tbl_password[user_id_A] == password_A) and sent random_A == received random_A. Close socket if failed
7. Server S marks that user_id_A is associated to transport_key_A

Call setup:
1. Client A sends AES_256(LIST_USER pdu, transport_key_A)
2. Server S returns AES_256(TLV_connected_user_ids, transport_key_A) to client A
3. Client A verifies that user_id_B is on the list, drop if failed
4. Client A sends AES_256(CALL_REQ(user_id_B), transport_key_A)
5. Server S sends AES_256(CALL_IND(user_id_B), transport_key_B) to client B
6. Client B sends AES_256(CALL_RSP(user_id_B), transport_key_B)
7. Server S sends AES_256(CALL_CNF(user_id_B), transport_key_A) to client A
8. Client A sends AES_256(RSA_8192(CHALLENGE_USER(rand_call_A), public_key_call[user_id_B]), transport_key_A)
9. Server S sends AES_256(RSA_8192(CHALLENGE_USER(rand_call_A), public_key_call[user_id_B]), transport_key_B) to client B
10. Client B verifies that rand_call_A was valid, send AES_256(CALL_DROP, transport_key_B) if failed
11. Client B sends AES_256(RSA_8192(CHALLENGE_USER(rand_call_B), public_key_call[user_id_A]), transport_key_B)
12. Server S sends AES_256(RSA_8192(CHALLENGE_USER(rand_call_B), public_key_call[user_id_A]), transport_key_A) to client A
13. Client A verifies that rand_call_B was valid, send AES_256(CALL_DROP, transport_key_A) if failed
14..Client A sends AES_256(voice_chuck_A, transport_key_A)
15. Server S sends AES_256(voice_chuck_A, transport_key_B) to client B
16..Client B sends AES_256(voice_chuck_B, transport_key_B)
17. Server S sends AES_256(voice_chuck_B, transport_key_A) to client A
18. Either Client A or client B sends AES_256(CALL_DROP, transport_key_X)
19. Server S forwards AES_256(CALL_DROP, transport_key_Y)

1. Client A holds CALL_PUBLIC_KEY of Client B and vice versa
2. Each client holds its own CALL_PRIVATE_KEY and AUTH_PRIVATE_KEY
3. Server S holds all AUTH_PUBLIC_KEY of all clients

Anyway, i’ll name it “pondoh”. A tasty breed of salak fruit :D

14 December 2010

Freescale QorIQ P2020 Security Engine : Channel

Filed under: Co-processor — Tags: , , , , , — edipermadi @ 9:13 am

The channel section at Security Engine gives you access to execution unit. 4 Channels are available for you to do multiple cryptographic processing at one time. The channel section is consisted of Channel Configuration Register (CCR), Channel Status Register (CSR), Current Descriptor Pointer Register (CDPR), Fetch FIFO Enqueue Register (FFER), Descriptor Buffer (DB), Scatter Link Tables (SLT), and Gather Link Tables (GLT). Please note that an execution unit may only be associated to a channel on each cryptographic session.

9 December 2010

Freescale QorIQ P2020 Security Engine : Playing with Controller

Filed under: Co-processor — Tags: , , , , , , — edipermadi @ 8:58 am

Controller is the housekeeping part of Security Engine that enables software to manage the whole security subsystem. The controller part is consisted of 6 64-bits register dealing with interrupt management, identification, status and master control. Each of those 64-bits register are organized in big-endian way.

The identification register enables you to use the same software for various version of SEC machine. The only thing you need is to determine the IP core version and enable / disable some software functionality to match the feature available on the engine.

The interrupt management register (IER, ICR, ISR) enables you to either check, enable or disable interrupt. The following list gives you the supported functionalities :

  • FIFO count rollover
  • Descriptor finished count rollover
  • Data in / out count rollover
  • Timeout
  • Channel done overflow
  • Channel done
  • Channel error
  • Execution unit done
  • Execution unit error

Master Control Register (MCR) enables you to remap, manage priority and reset the whole security engine. Finally, the assignment status register (EUASR) enables you to check whether a particular execution unit is currently assigned to channel or not.

Take a look on the following implementation of those controller registers in C.

typedef struct sec_reg_ctrlr_iex_t
    unsigned int rsvd_0   : 8;
    unsigned int FFE_CNT  : 1;  /* Fetch FIFO enqueue count rollover          */
    unsigned int DF_CNT   : 1;  /* Descriptor Finished Count Rollover         */
    unsigned int DI_CNT   : 1;  /* Data In Count Rollover                     */
    unsigned int DO_CNT   : 1;  /* Data Out Count Rollover                    */
    unsigned int rsvd_1   : 3;
    unsigned int ITO      : 1;  /* Internal Time Out                          */
    unsigned int rsvd_2   : 4;
    unsigned int CH4_DNOV : 1;  /* Channel 4 Done Overflow                    */
    unsigned int CH3_DNOV : 1;  /* Channel 3 Done Overflow                    */
    unsigned int CH2_DNOV : 1;  /* Channel 2 Done Overflow                    */
    unsigned int CH1_DNOV : 1;  /* Channel 1 Done Overflow                    */
    unsigned int CH4_ERR  : 1;  /* Channel 4 Error                            */
    unsigned int CH4_DN   : 1;  /* Channel 4 Done                             */
    unsigned int CH3_ERR  : 1;  /* Channel 3 Error                            */
    unsigned int CH3_DN   : 1;  /* Channel 3 Done                             */
    unsigned int CH2_ERR  : 1;  /* Channel 2 Error                            */
    unsigned int CH2_DN   : 1;  /* Channel 2 Done                             */
    unsigned int CH1_ERR  : 1;  /* Channel 1 Error                            */
    unsigned int CH1_DN   : 1;  /* Channel 1 Done                             */
    unsigned int rsvd_3   : 4;
    unsigned int CRCU_ERR : 1;  /* CRCU Error                                 */ 
    unsigned int CRCU_DN  : 1;  /* CRCU Done                                  */
    unsigned int KEU_ERR  : 1;  /* KEU  Error                                 */
    unsigned int KEU_DN   : 1;  /* KEU  Done                                  */
    unsigned int STEU_ERR : 1;  /* STEU Error                                 */
    unsigned int STEU_DN  : 1;  /* STEU Done                                  */
    unsigned int PKEU_ERR : 1;  /* PKEU Error                                 */
    unsigned int PKEU_DN  : 1;  /* PKEU Done                                  */
    unsigned int rsvd_4   : 2;
    unsigned int RNG_ERR  : 1;  /* RNGU Error                                 */
    unsigned int RNG_DN   : 1;  /* RNGU Done                                  */
    unsigned int rsvd_5   : 2;
    unsigned int AFEU_ERR : 1;  /* AFEU Error                                 */
    unsigned int AFEU_DN  : 1;  /* AFEU Done                                  */
    unsigned int rsvd_6   : 2;
    unsigned int MDEU_ERR : 1;  /* MDEU Error                                 */
    unsigned int MDEU_DN  : 1;  /* MDEU Done                                  */
    unsigned int rsvd_7   : 2;
    unsigned int AESU_ERR : 1;  /* AESU Error                                 */
    unsigned int AESU_DN  : 1;  /* AESU Done                                  */
    unsigned int rsvd_8   : 1;
    unsigned int DEU_ERR  : 1;  /* DEU  Error                                 */
    unsigned int DEU_DN   : 1;  /* DEU  Done                                  */

typedef struct sec_reg_ctrlr_id_t
    unsigned int IP_ID    : 16; /* IP block identifier                        */
    unsigned int IP_MJ    :  8; /* IP Major revision number                   */
    unsigned int IP_MN    :  8; /* IP Minor revision number                   */
    unsigned int rsvd_0   :  8;
    unsigned int IP_INT   :  8; /* IP block integration options               */
    unsigned int rsvd_1   :  8;
    unsigned int IP_CFG   :  8; /* IP block configuration options             */

typedef struct sec_reg_ctrlr_euasr_t
    unsigned int rsvd_0 : 4;
    unsigned int AFEU   : 4;    /* AFEU Assignment Status Register            */
    unsigned int rsvd_1 : 4;
    unsigned int MDEU   : 4;    /* MDEU Assignment Status Register            */
    unsigned int rsvd_2 : 4;
    unsigned int AESU   : 4;    /* AESU Assignment Status Register            */
    unsigned int rsvd_3 : 4;
    unsigned int DEU    : 4;    /* DEU  Assignment Status Register            */
    unsigned int rsvd_4 : 8;
    unsigned int CRCU   : 4;    /* CRCU Assignment Status Register            */
    unsigned int rsvd_5 : 4;
    unsigned int STEU   : 4;    /* STEU Assignment Status Register            */
    unsigned int PKEU   : 4;    /* PKEU Assignment Status Register            */
    unsigned int rsvd_6 : 4;
    unsigned int RNGU   : 4;    /* RNGU Assignment Status Register            */

typedef struct sec_reg_ctrlr_mcr_t
    unsigned int rsvd_0          : 16;
    unsigned int RCA1            :  1;  /* Remap Channel Address 1            */
    unsigned int RCA2            :  1;  /* Remap Channel Address 2            */
    unsigned int RCA3            :  1;  /* Remap Channel Address 3            */
    unsigned int RCA4            :  1;  /* Remap Channel Address 4            */
    unsigned int rsvd_1          :  2;
    unsigned int PRIORITY        :  2;  /* Priority on Master Bus             */
    unsigned int rsvd_2          :  6;
    unsigned int GIH             :  1;  /* Global Inhibit                     */
    unsigned int SWR             :  1;  /* Software Reset                     */
    unsigned int CHN3_EU_PR_CNT  :  8;  /* Channel 3 EU Priority Count        */
    unsigned int CHN4_EU_PR_CNT  :  8;  /* Channel 4 EU Priority Count        */
    unsigned int CHN3_BUS_PR_CNT :  8;  /* Channel 3 Bus Priority Count       */
    unsigned int CHN4_BUS_PR_CNT :  8;  /* Channel 4 Bus Priority Count       */

typedef struct sec_reg_ctrlr_t{
    SEC_REG_CTRLR_IEX_T   IER;      /* Interrupt Enable Register              */
    SEC_REG_CTRLR_IEX_T   ISR;      /* Interrupt Status Register              */
    SEC_REG_CTRLR_IEX_T   ICR;      /* Interrupt Clear Register               */
    SEC_REG_CTRLR_ID_T    ID;       /* Identification Register                */
    SEC_REG_CTRLR_EUASR_T EUASR;    /* EU Assignment Status Register          */
    SEC_REG_CTRLR_MCR_T   MCR;      /* Master Control Register                */

8 December 2010

Freescale QorIQ P2020 Security Engine : Register Map

Filed under: Co-processor — Tags: , , , , , , — edipermadi @ 9:24 am

The Register map of Freescale Security Engine located to CCSR and its position is relative to CCSRBAR (CCSR Base Address Register). In general, CCSRBAR contains 0xff70000 and the register map of Security Engine itself is located at CCSRBAR + 0×30000.

The Security Engine register map is mainly divided into Channel, Controller and Execution Unit. As you refer to the block diagram of Security Engine, you will find that those three items are the main ingredients of the Security Engine. In fact, the real application of Security Engine stuff will require you to access controller and channel register only. Execution register is provided just for the sake of debugging.

The controller section is taking care of Security Engine IP Core version identification, interrupt status and management, and some master accessibility stuff such as master reset.

The channel block section itself is a group of four channel section. Each unit corresponds to a channel and its housekeeping functionality, which includes channel configuration, FIFO management, as well as status.

Please refer to global and detailed structure of Security Engine shown below.

Security Engine Register Map : Global
P2020 Security Engine Register Map

Security Engine Register Map : Detailed

Detailed P2020 Security Engine Register Map

1 December 2010

Freescale QorIQ P2020 Security Engine : Talking in Descriptor Language

Filed under: Co-processor, encryption — Tags: , , , , , , — edipermadi @ 8:45 am

This issue will introduce how you talk to Freescale QorIQ P2020 Security Engine. Actually the Freescale Security Engine works in memory map may. You will find a specific region in memory map which reflect the internal structure of Security Engine itself.

The way you talk to Security Engine is about the way you express your cryptographic needs in terms of descriptor. Descriptor is a structure that bundles required cryptographic requirements as well as its arguments. Fortunately, the structure is implementable as a “struct” in C language. This will ease development and reduce your pain. See the following illustration the block diagram of a descriptor.

P2020 Security Engine Descriptor

The content of a descriptor includes a header and 7 pointers. A header is a 64-bits field occupied by descriptor control and descriptor feedback. Descriptor control subfield explains Security Engine which execution unit to be used and which mode should be performed.

Descriptor control subfield also describes the type of descriptor that also explains which pointer fields to be used in terms of current cryptographic context. Descriptor feedback subfield correspond to the write-back process done by Security Engine to indicate that a cryptographic processing is done. For your information, execution unit reflects the algorithm to be used.

The seven unit of 64-bits pointer reflects the arguments to be used in current cryptographic processing. A pointer field contains an actual pointer to incoming or outgoing arguments as well as its length and some little more advance configuration. Please be informed that a descriptor of a cryptographic context may not use the whole seven pointer fields. If the context requires plain text, cipher text, key and iv thus only 4 out of 7 pointers are being used.

In the illustration above, the leftmost bit, which is zero, corresponds to the most significant bit while the rightmost bit, which is sixty three, corresponds to least significant bit. The structure is exactly match on big endian machine which is P2020 itself. I give an example of descriptor in terms of C struct model.

typedef struct desc_hdr_ctrl_t
    unsigned int eu_sel0   : 4;
    unsigned int mode0     : 8;
    unsigned int eu_sel1   : 4;
    unsigned int mode1     : 8;
    unsigned int desc_type : 5;
    unsigned int reserved  : 1;
    unsigned int dr        : 1;
    unsigned int dn        : 1;

typedef struct desc_hdr_fdbk_t
    unsigned int reserved_1 :  3;
    unsigned int iccr0      :  2;
    unsigned int reserved_2 :  6;
    unsigned int iccr1      :  2;
    unsigned int reserved_3 :  3;
    unsigned int id_tag     : 16;

typedef struct desc_hdr_t
    DESC_HDR_CTRL_T control;
    DESC_HDR_FDBK_T feedback;

typedef struct desc_ptr_t
    unsigned int   length   : 16;
    unsigned int   j        : 1;
    unsigned int   extent   : 7;
    unsigned int   reserved : 4;
    unsigned int   eptr     : 4;
    unsigned char *ptr;

typedef struct sec_desc_t
    DESC_HDR_T header;
    DESC_PTR_T pointer[7];    

18 November 2010

Freescale QorIQ P2020 Security Engine : Introduction

Filed under: Co-processor — Tags: , , , , , , , — edipermadi @ 1:01 pm

QorIQ P2020 is dual core integrated communication processor manufactured by Freescale. P2020 is designed based on PowerPC e500 architecture. The processor contains supporting system for networking, telecommunication, and wireless infrastructure. One of the powerful supporting system is the on-chip crypto processor that enables intensive security function such as echipherment, key generation and exchange, and authentication to be offloaded.

The P2020 security engine (SEC) is basically an on-chip co-processor that is designed to perform several cryptographic function within a specified range of system memory given by processor. The security engine itself is addressable through memory map and the mechanism is as easy as register transfer. The security engine will decode each descriptor packet and utilize supplied pointers as incoming and resulting buffer.

The P2020 SEC memory map can be divided into controller, channels and execution unit. The “controller” region is is taking care of controlling the whole security engine such as assignment, status, identification, and master control. The execution unit region is consisted of several execution unit. Each of them are taking care specific cryptographic function assigned by particular channel. The channels region contains 4 channels. Each channel is taking care of particular cryptographic function assigned to particular execution unit. Each channel could be associated to any execution unit, but only one execution unit can associated to a specific channel.

The purpose of channeling is to enable the multiple cryptographic processing. User may use simple “round robin” scheduling or “prioritized scheduling” to utilize those four channels. Thus, user may process up to four cryptographic processing in parallel. Moreover, P2020 Security Engine also support compound cryptographic processing, when a cryptographic inputs are taken from the output of previous cryptographic processing.

The P2020 Security Engine has capability of doing IKE, SSL/TLS, iSCSI, SRTP, 802.11i, WiMAX, 3G, A5/3 for GSM and EDGE, and GEA3 for GPRS. Those functionalities are made of several execution unit such as AESU (Advanced Encryption Standard Unit), AFEU (Alleged RC4 Execution Unit), CRCU (Cyclical Redundancy Check Unit), DEU (Data Execution Unit), KEU (Kasumi Execution Unit), STEU (SNOW3G Execution Unit), MDEU(Message Digest Execution Unit), PKEU (Public Key Execution Unit) and RNGU (Random Number Generator Unit). Each execution unit are equipped by FIFO-in and FIFO-out mechanism, except RNGU MDEU and CRCU.

4 November 2010

Moving to LPC2103

Filed under: personal — Tags: , — edipermadi @ 11:52 pm

I’ve got a new 32-bit microcontroller board (MCB2103) 3 months ago. I tried to google around to set-up my cross compiler to work for LPC2103. You know, I found myself lost and desperate, haha :D.

Finally, some couple weeks ago i found a nice blog provided me how to setup gcc to work for LPC2103.

My first attempt was to create chasing light on it’s GPIO and guest what, it works.

I know, it’s quite a long time i discarded this blog. I researched nothing and i have nothing to post. My job really takes my concentration a lot. I really missed the moment when i was taking my undergraduate degree, taking small research and post some crypto stuff.

My current project forces me to focus on P2020 Security Engine (SEC 3.1) to bring up all cryptographic functionality within RTOS platform. I hope someday i could write some more advanced cryptographic stuff about P2020 Security Engine, just for the sake of fun. All GPL, all open source.

For the short term. I’ll do a small research to implement a full speed (115200bps) RS232 encryptor based on LPC2103. This would be my first crypto stuff on ARM based processor :D.

1 June 2010

Oldskool Memory Skrambler

Filed under: Uncategorized — Tags: , , , , , , — edipermadi @ 10:55 am

Memory scrambling is the process of messing up the contents of memory, either by remapping the adress, data encipherment or even both of them. The aim is to complicate data retrieval from memory, this is also useful to protect a small and sensitive stuff such as firmware.

The address remapping itself is nothing new, its actually a bijective mapping of plain address to scrambled address. In real life this keyed scrambling is made through the usage of block cipher. The mode could be enciphering or deciphering, since address scrambling is a one way mapping.

The content encipherment is working in the same way as address scrambling. It is also based on block cipher. However, content encipherment is sensitive to address and direction since the process must be able to recover the data stored at memory. The writing processis encipherment while the reading process is decipherment.

Now, let’s make it works. Supposed i have an oldskool 8051 development board with a 64 kilo-byte SRAM extension attached, and i wanted to protect the thing i stored in memory.

The 64 kbytes of SRAM takes 16-bits of address 8-bits of data with two additional control RD and WR. Here, as a prototype, we can use S-AES (a 16-bits block cipher with 16-bits of key) to scramble the address either in enciphering and deciphering mode. The 8-bits of content will be scrambled using S-DES (a 8-bits block cipher with 10-bits of key).

As a keying mechanism, the address scrambling will be keyed by a 17-bits key (16 from S-AES and 1 form encipherment/decipherment selection) while the content encipherment will be keyed by a 10-bits key with the addition of scrambled address to make the encipherment varies along the position. The total keyspace is 27-bit or about 128 million of combinations.

Here is the block diagram.

Oldskool SRAM Scrambler

In real life, we need such two microcontrollers with 32 bits GPIO. The first microcontroller is responsible of scrambling the address using S-AES while the other one is responsible of scrambling the content using S-DES.

Haha, you know this is kinda stupid implementation, 27 bits of keyspace is to easy to break. It takes several seconds in a fast computer to brute force all combination. It’s just like nothing but who care . I belief that this scheme works better at larger memory space such as 128-bit that enables the usage of AES.

I am currently developing the software for both microcontroller. I chose AVR for simplicity reason. The code will be posted here and hosted at

2 November 2009

A Compact Implementation of Grain Cipher using PIC16F84

This post demostrates an example of compact grain cipher implementation using PIC16F84, a stream cipher invented by Martin Hell, Thomas Johansson and Willi Meier. This stream cipher is based on Linear Feedback Shift Register (LFSR) and non-linear feedback shift register (NFSR).

The core of this cipher are two shift registers, two tapping function for determining the next state of the cipher. The last filtering function is used to determine the bit stream output based on the current cipher state.

All shift registers are emulated as 8 consecutive registers which is treated as a unity. The linear boolean function are implemented on the fly while non-linear boolean function are stored as a lookup table to save memory usage and to simplify the implementation.

I have tested the source source code against several known test vector. Here is the example.

Test Vector
Cipher Key : 44 44 44 44 44 44 44 44 44 44
IV : 55 55 55 55 55 55 55 55
Bit Stream : aa 65 8e e6 45 ef d3 4f 34 28

test vector result:

The code is released for free under the term of GNU Public License v3.0 without any warranty implied. You may use this code for educational purpose only.

Related Stuff

Source Code | v1.0 | v1.1
Grain Stream Cipher Specification
MPLAB 8.40

Grain Cipher

22 June 2009

Embedding The Enigma Railway into ATMega32

Filed under: Cipher Machine, classical — Tags: , , , , , , — edipermadi @ 12:20 pm

A couple weeks ago, i have ported the implementation of Enigma Railway from PIC16F84 based to the one geared by ATMega32 running at 16 MHz. The code is rewriten from assembly to C for better understanding.

The hardware is based on ATMega8535 development board produced by innovative electronics with small changes on system frequency and microcontroller replacement. The code is compiled using codevision 1.25.3 and you may use another compiler with minor changes. The code is freely available for anyone under the GNU Public License 3.0 terms. You way use and modify it with no warranty implied.

In this post, i used the ATMega32 to continuously monitor the serial connection form PC to microcontroller (at 115200) for incoming data. Once [a-z:A-Z] characeter found, i’t will subsequentially encode the incoming character through Enigma Railway substitution cipher and pass back the result. The PC side control is hosted by Teraterm configured at 115200 8n1 with no flow control.

The code is verified against the “Enigma Railway Simulator” coded by Geoff Sullivan found here. The test vector comparison is performed by enciphering 600 of “A” characters using the same initial condition

In addition, i used several number and symbol to control the inner state of Enigma Railway Cipher Machine. The Control Character is shown at screenshot section below.

Development Board
The ATMega32 Development Board

AVR USB Programmer
The AVR USB Programmer

Menu Page
The Enigma Railway Help Menu

About Page
The Enigma Railway About Page

Licensing Page
The Enigma railway Licensing Page

Usage Page
The Enigma Railway Usage Page

Resulting Cipher
The Enigma Railway Resulting Cipher

The Enigma Railway Simulator
The Enigma railway Simulation Result

After your compiled and burned the HEX code to the chip, you can connect it to PC and type “?” (a question mark) to display those menus.

Related Stuff

Enigma Railway AVR Source Code v0.1

Older Posts »

The Silver is the New Black Theme Blog at


Get every new post delivered to your Inbox.