Professional Documents
Culture Documents
Smart Card 01
Smart Card 01
by
September 2001
chris@phaedsys.org
www.phaedsys.org
Release notes:-
This document was originally produced as an internal document for a smart card project in
the UK in 1997-8. All the company/project specific parts have been removed and only
generic 7816, EMV, UKIS and cipher information remains. UKIS is a subset of 7816 used in UK
for APACS financial smart cards.
The cipher sources have been collected from several places all of them reputable but for
obvious reasons some of them are not attributed. None of them come with no guarantees of
any kind. You have to validate them for your own use.
Apart from MAC’s they system requires transaction certificates that are also generated using
DEA in a similar manner to the MAC.
The card also contains other (RSA) keys that can be recovered from the card, using Read
Record that the terminal uses for static authentication. This does not require any involvement
by the card other than supplying the files.
There is also a method of read write access to the application and files. This is part of the file
system and outside the scope of this document.
External Authenticate
With the exception of the Generate AC all the commands receive a MAC or encrypted data.
They have to authenticate the command. With Gen AC the card receives a request for a an
encrypted certificate. The certificate it returns depends on the card risk management data.
Issuer script commands use secure messaging because they flow from the issuer not the
terminal. The terminal does not interpret the messages.
Taking the Issuer script commands as a group they work as follows: The Issuer constructs the
message, which is sent to the terminal. The terminal sends the command to the card without
interpretation. The card validates the command and executes it. Issuer script commands may
contain data. For this implementation of UKIS only Put Data contains data, a one byte Lower
Consecutive Offline Limit (LCOL). In all cases the MAC is the last element of the message. The
Issuer Script Commands apply only to applications loaded during personalisation.
All the UKIS issuer Scripts only return SW1/SW2 ie NO RETURN DATA
The MAC is generated using all the command. UKIS (E 2.2 MAC Length) mandates the MAC is
8 bytes. In ALL cases the MAC is the last element of the command sent.
NB The MAC may, under EMV rules be 4 to 8 bytes and Visa recommends 4 bytes.
The second nibble of the CLA is 4h indicating secure messaging. The lead nibble of CLA
indicates the following: 8h = A standard ISO7816 format command that has proprietary
command and response. Fro Put Data 0h = ISO7816 command.
All data required to perform the Issuer Script Command shall be available to both Issuer and
the card operating system.
Whilst UKIS D2.1.2 Command Message section of Application Block states that “the header
consists of CLA, INS, P1 and P.” in UKIS E2.4 MAC Computation Step 2 it states “The
following data is concatenated in the order specified to create a block of data: CLA, INS, P1,
External Authenticate
Returns SW1/SW2
Generate AC
Generate Application Cryptogram is the only command that causes a cryptogram to be
generated and returned.
Command :
CLA, INS, P1, P2, Lc, Data
0x80 0xAE 0x00 0x00 0x1D CDOL1
0x40 0x1F CDOL2
0x80
This 64-bit block cipher is the approved algorithm for secure messaging and
is standardised in ISO 8731-1, ISO 8372, and ISO/IEC 10116. More precisely,
both the single DES encipherment and the triple DES encipherment versions
described below are approved to be used in the encipherment and MAC
mechanisms described in Annex E.
Y = DES(KL)[DES-1(KR)[DES(KL)[X]]].
X = DES-1(KL)[DES(KR)[DES-1(KL)[Y]]].
.
The encipherment mechanisms for secure messaging for confidentiality uses a
64-bit block cipher ALG either in Electronic Codebook (ECB) Mode or in
Cipher Block Chaining (CBC) mode.
If the message MSG has a length that is not a multiple of 8 bytes, add a ‘80’
byte to the right of MSG, and then add the smallest number of ‘00’ bytes to the
right such that the length of resulting message MSG := (MSG || ‘80’ || ‘00’ ||
‘00’ || . . . || ‘00’) is a multiple of 8 bytes.
If the message MSG has a length that is a multiple of 8 bytes, the following two
cases can occur depending on pre-defined rules (see Part IV of this
specification).
to obtain MSG.
ECB Mode
Encipher the blocks X1, X2, . . . , Xk into the 8-byte blocks Y1, Y2, . . . , Yk with
the block cipher algorithm in ECB mode using the Encipherment Session Key
KS. Hence compute for i = 1, 2, . . . , k:
Yi := ALG(KS)[Xi].
CBC Mode
Encipher the blocks X1, X2, . . . , Xk into the 8-byte blocks Y1, Y2, . . . , Yk with
the block cipher algorithm in CBC mode using the Encipherment Session Key
KS. Hence compute for i = 1, 2, . . . , k:
Yi := ALG(KS)[Xi ⊕ Yi-1],
with initial value Y0 := (‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ ||
‘00’).
Notation:
Y := (Y1 || Y2 || . . . || Yk) = ENC(KS)[MSG].
Decipherment is as follows.
Cryptogram Decipherment
ECB Mode
Compute for i = 1, 2, . . . , k:
Xi := ALG-1(KS)[Yi ].
CBC Mode
Compute for i = 1, 2, . . . , k:
Xi := ALG-1(KS)[Yi ] ⊕ Yi-1,
with initial value Y0 := (‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’).
To obtain the original message MSG, concatenate the blocks X1, X2, . . . , Xk
and if padding has been used (see above) remove the trailing (‘80’ || ‘00’ ||
‘00’ || . . . || ‘00’) byte-string from the last block Xk.
Notation:
M = DEC(KS)[Y].
Unique Keys
The Unique DEA Keys are used to perform online card authentication, online
issuer authentication and TC generation. The Unique DEA keys are stored in
the card during personalisation and are derived using the Application PAN1
and Application PAN Sequence Number.
To derive the Unique Key A, the Application PAN and Application PAN
Sequence Number are concatenated together into a 16-hexadecimal field. If
the Sequence Number is not present then it is zero filled. If the length of the
Application PAN followed by the Sequence Number is not equal to 16 digits
then the following rules apply:
− if the PAN plus the Sequence Number are less than 16 digits the
data is right justified in a 16-hexadecimal field and padded on the
left with ‘0’s
− if the PAN plus the Sequence Number are greater than 16 digits
only the rightmost 16 digits are used
To derive the Unique Key B, the Application PAN and Application PAN
Sequence Number are concatenated together into a 16-hexadecimal field
using the formatting rules above and then inverted. Inversion takes place at
bit level where each bit with the value ‘1’ is set to ‘0’ and each bit with the
value ‘0’ is set to ‘1’.
1
Primary Account Number
The MAC DES Keys are calculated using the MAC Master Derivation Key and same method as
the Unique Keys. These are also generated and stored at personalisation time.
The calculation of the MAC requires the use of MAC Session Keys, which are
derived using the card’s MAC DES Keys.
Session keys KS for secure messaging for integrity and confidentiality are
derived from unique Master Keys KM using diversification data R provided by
the receiving entity, hence
KS := F(KM)[R].
The only requirement for the diversification function F is that the number of
possible outputs of the function is sufficiently large and uniformly distributed
to prevent an exhaustive key search on the session key.
The result of the exclusive-OR is session key A for the ‘Maccing’ process.
− The inverted ATC is then right justified in an 8-byte field and the
remaining 6 bytes are set to 0x00.
The result of the exclusive-OR is session key B for the ‘Maccing’ process.
Session Key
Create Session Created
Key
Creat Session
Key
Create Key A
Create Key B
Session Key
Session Key B Created
A Created
THEORY
The computation of an s-byte MAC (4 ≤ s ≤ 8) is according to ISO/IEC 9797 using a 64-bit
block cipher ALG in CBC mode. More precisely, the computation of a MAC S over a
message MSG consisting of an arbitrary number of bytes with a MAC Session Key KS takes
place in the following steps.
Pad the message M according to ISO 7816-4 (which is equivalent to method 2 of ISO/IEC
9797), hence add a mandatory ‘80’ byte to the right of MSG, and then add the smallest
number of ‘00’ bytes to the right such that the length of resulting message MSG := (MSG
|| ‘80’ || ‘00’ || ‘00’ || . . . || ‘00’) is a multiple of 8 bytes.
The MAC Session Key KS either consists of only a leftmost key block KS = KSL or the
concatenation of a leftmost and a rightmost key block KS = (KSL || KSR).
Cryptogram Computation
Process the 8-byte blocks X1, X2, . . . , Xk with the block cipher in CBC mode using the
leftmost MAC Session Key block KSL:
with initial value H0 := (‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’).
• Compute the 8 byte block Hk+1 in one of the following two ways. According to the
main process of ISO/IEC 9797:
Hk+1 := Hk.
Hk+1 := ALG(KSL)[ALG-1(KSR)[Hk]].
The MAC is generated using triple DEA encipherment with the MAC session
keys previously calculated as follows:
DATA NOTES
CLA Bytes of the script command sent to the card from the
INS terminal
P1
P2
Lc
ATC The last ATC sent to the terminal in the ‘Generate AC’
command
ARQC The last application cryptogram sent to the terminal in
the ‘Generate AC’ command
DATA Any ‘plain text’ data in the data field of the command
i.e. the Put Data’ command it would be the new value
for LCOL
− This block of data is formatted into 8-byte data blocks labelled D1,
D2, D3…D6…, (the last block may be between 1 and 8 bytes
depending on the length of the original data block)
80 00 00 00 00 00 00 00
Note: The number of data blocks will depend on the original data block.
Steps 4 and 5 are then repeated for the number of data blocks that exist until
an exclusive-OR has been performed on the last data block, D(n), and the
result has been encrypted to give the output O(n).
6 O(n) is then decrypted using the DES decrypt algorithm and the MAC
session key B to give the output O(n + 1)
7 O(n + 1) is then encrypted using the DES encrypt algorithm and the
MAC session key A to give the output O(n + 2)
The MAC is then compared to the MAC in the Command Data. This procedure
is shown diagrammatically below:
Initial I2 I3 I4 I5
Vector
Calculated
I = Input D = Data Block 8 – byte MAC
DEA (e) = Encrypt using MAC O = Output
Session Key A
DEA (d) = Decrypt using MAC = Exclusive Or
Xor
Session Key B
Referenced in the card’s CDOL, and transmitted from the terminal to the card
in the ‘Generate AC’ command
or
The data elements that need to be accessed internally by the card for input
into the algorithm are:
Depending upon the result of the internal card risk management tests
performed by the card, a TC, an AAC or an ARQC will be returned in the
response message.
The card concatenates the data received in the ‘Generate AC’ command. This
data is referenced by the CDOL and is placed in the order specified by the
CDOL into a data block.
The card concatenates the AIP, ATC and CVR onto the end of the data block.
The card will then format the data block into smaller 8-byte blocks labelled
D1, D2, D3, D4 and D5.
As the data block D5 is less than 8-bytes in length the remaining right bits are
set to 0x00.
Using the unique DES keys A and B on the card the following steps are
performed:
The output 8-byte field is the resulting cryptogram returned by the card in
response to the ‘Generate AC’ command
I1 = D1 I2 I3 I4 I5
O1 O2 O3 O4 O5
O6
Calculated
I = Input D = Data Block 8 – byte Cryptogram
DEA (e) = Encrypt using DES O = Output
with Key A
DEA (d) = Decrypt using DES Xor = Exclusive Or
with Key B
D1 is encrypted using the DES algorithm and the DES Key A on the card
to give an output O1
O1 is decrypted using the DES algorithm and DES Key B to give an
output O2
O2 is encrypted using the DES algorithm and the DES Key A on the card
to give an output O3. O3 is the 8-byte ARPC which is used to verify the
ARPC sent to the card in the ‘External Authenticate’ command by the
terminal
I1 = D1
DEA(e)
O1
DEA(d)
O2
DEA(e)
O3
Calculated
ARPC
Static data authentication is performed by the terminal using a digital signature based on
public key techniques to confirm the legitimacy of critical ICC-resident static data identified
by the AFL. This detects unauthorised alteration of data after personalisation.
The data objects used for signing shall be retrievable by the terminal using the READ
RECORD Command.
RSA
Static data authentication requires the existence of a certification authority, which is a highly
secure cryptographic facility that ‘signs’ the issuer’s public keys. Every terminal conforming
to this specification shall contain the appropriate certification authority's public key(s) for
every application recognised by the terminal. This specification permits multiple AIDs to
share the same ‘set’ of certification authority public keys. The relationship between the data
and the cryptographic keys is shown below.
Distributed to Acquirer
Private Key Public Key Private Key Public Key (Resides in Terminal)
(Issuer) (Issuer) (CA) (CA)
SI PI SCA PCA
PI certified
with SCA
IC Card IC Terminal
Communication between IC Card and Terminal
Terminal :
Card provides to terminal :
- Uses PCA to verify that the Issuer’s PI
- PI certified by Certification Authority
was certified by the CA
- Card data with digital signature
- Uses PI to verify the digital signature
of the card data
Issuer’s public key certified by a certification authority for use in static data authentication.
Format:
Issuer specified data to be used with the Issuers’s public key algorithm for use in static data
authentication.
Format:
Format:
The cipher sources have been collected from several places all of them
reputable but for obvious reasons some are not attributed and come with
no guarantees of any kind.
As all these ciphers are in the public domain the sources will be available on my web site
(unless or until lawyers tell me different) The C version of DES is available on the Keil CD in
the 8051 examples directory. It originated from Applied Cryptography by Bruce Schneier
however due to the wonderfully democratic laws of the US whilst it was in printed from in the
book the electronic version on the Applied Cryptography CD is only available in the USA.
Bruce Schneier is an internationally acclaimed security and cipher consultant who does not
need me to validate the authenticity of his work. The 8051 assembler implementation comes
from an unimpeachable source at a major smart card vendor. The SHA-1 cipher comes from
another smart card vendor.
DES Sources
C Source
The DES example is taken from the book "Applied Cryptography" by Bruce Schneier. It is
adapted for the Keil C51-Compiler. The example code is not optimized for code or data
space and shows the processing from long value arithmetic (56 bit) on an 8051 micro
controller. The source is available on the Keil demo CD
cpkey
Des.c
des_enc desfunc
Des.c Des.c
main
Des.c
des_dec unscrun
Des.c Des.c
scrunch
Des.c
typedef struct {
unsigned long ek[32];
unsigned long dk[32];
} des_ctx;
cook = dough;
for( i = 0; i < 16; i++, raw1++ ) {
raw0 = raw1++;
*cook = (*raw0 & 0x00fc0000L) << 6;
*cook |= (*raw0 & 0x00000fc0L) << 10;
*cook |= (*raw1 & 0x00fc0000L) >> 10;
*cook++|= (*raw1 & 0x00000fc0L) >> 6;
*cook = (*raw0 & 0x0003f000L) << 12;
*cook |= (*raw0 & 0x0000003fL) << 16;
*cook |= (*raw1 & 0x0003f000L) >> 4;
*cook++ |= (*raw1 & 0x0000003fL);
}
usekey(dough);
}
#if 0
void des(unsigned char *inblock, unsigned char *outblock) {
unsigned long work[2];
scrunch(inblock, work);
desfunc(work, KnL);
unscrun(work, outblock);
}
#endif
leftt = block[0];
right = block[1];
work = ((leftt >> 4) ^ right) & 0x0f0f0f0fL;
right ^= work;
leftt ^= (work << 4);
/* Validation sets:
*
* Single-length key, single-length plaintext -
cp = Data;
for(i=0;i<blocks;i++){
scrunch(cp,work);
desfunc(work,dc->ek);
unscrun(work,cp);
cp+=8;
}
}
cp = Data;
for(i=0;i<blocks;i++){
scrunch(cp,work);
desfunc(work,dc->dk);
unscrun(work,cp);
cp+=8;
}
}
void main(void){
des_ctx dc;
int i;
unsigned long Data[10];
char *cp,key[8] = {0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xef};
char x[8] = {0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xe7};
/*------------------------------------------------
Setup the serial port for 1200 baud at 16MHz.
------------------------------------------------*/
SCON = 0x50; /* SCON: mode 1, 8-bit UART, enable rcvr */
TMOD |= 0x20; /* TMOD: timer 1, mode 2, 8-bit reload */
TH1 = 221; /* TH1: reload value for 1200 baud @ 16MHz */
TR1 = 1; /* TR1: timer 1 run */
TI = 1; /* TI: set TI to send first char of UART */
cp = x;
des_key(&dc,key);
des_enc(&dc,cp,1);
printf("Enc(0..7,0..7) = ");
des_dec(&dc,cp,1);
printf("Dec(above,0..7) = ");
for(i=0;i<8;i++) printf("%02x ",((unsigned int)cp[i])&0x00ff);
printf("\n");
cp = (char *) Data;
for(i=0;i<10;i++) Data[i]=i;
des_dec(&dc,cp,1);
des_dec(&dc,cp+8,4);
for(i=0;i<10;i+=2) printf("Block %01d = %08lx %08lx.\n",
i/2,Data[i],Data[i+1]);
while (1);
The source below has come from a very good source (sic) that wishes not to advertise that it is
their implementation. However I know it has been tested and used at the highest levels.
;******************************************************************
;*
;* $Workfile: DES.A51 $
;* NAME : DES
;*
;* Copyright *******
;*
;* Author: **********
;* $Revision: 1 $
;*
;* Analysis reference:
;*
;* Input Parameters:
;*
;* Output Parameters:
;*
;* Compiler : Keil A51 Asembler
;* Target :
;*
;* $Log: /des2/DES.A51 $
;*
;* 1 4/08/01 11:36 Chris
;*
;/
;***********************************************************************
**
DES: Mov A, R5 ;mode
Jnb MAC,DES_
Jnb Decode,DES_
;Separate MAC at the end of the datafeild
Mov A, R7 ;Acc := #(Data) + # (MAC)
Add A, #0F8h ;Acc -= #(MAC)
Mov R7, A ;R7 := true DataLength
Jnc $+5
Inc R2
Mov A, R2 ;Acc := addr(VectorI)
MovC A, @A+Dptr ;Acc :=VectorI
Inc R1 ;addr (0) += 1
Mov R3, $-7
Mov A, R5 ;Acc :=
Parameter2 of APDU
Anl A, #030h ;Acc5..4 := decode~, BuildMac
Jnz InitExpand
Mov A, R5
Jb Acc.4, TestEnd ;BuildMac ?
Rl A
Rlc A
Anl C, /Acc.7 ;Carry := Mode is CBC decode
TestEnd: Mov A, R7
NoMAC: Mov A, R6
Mov R1, A
Mov A, #8
Clr c
Ret ;Normal termination => Carry == 0!
VecExist: Mov A, #2
MovC A, @A+Dptr ;Acc :=KeyType
Rrc A ;Carry :=InitialVectorExistanc
Mov A, #1
MovC A, @A+Dptr ;Acc := HeaderLength
;***********************************************************************
* SBOX DATA */
SBoxes: ;BoxNr.: 2,1 4,3 6,5 8,7
DB 0F7h,0E5h,034H,02Bh
DB 002h,05Bh,092h,0E8h
DB 09Ch,088h,001h,05Ch
DB 0AFh,0DFh,0EFh,005h
DB 046h,006h,09Eh,06Fh
DB 05Bh,031h,045h,093h
DB 03Ah,0DDh,07Bh,0AAh
DB 09Ch,0AAh,086h,0F0h
DB 01Bh,079h,052h,014h
DB 0E7h,092h,0F8h,02Dh
DB 046h,013h,0CCh,0C9h
DB 039h,0C4h,023h,056h
DB 0CDh,09Fh,06Dh,0d1h
DB 0B4h,0ECh,03Eh,07Eh
DB 0A0h,024h,0A7h,036h
DB 04Ah,017h,0D0h,0A9h
DB 082h,0B0h,083h,04Dh
DB 078h,066h,074h,0D2h
DB 0E5h,04Bh,0BAh,093h
DB 013h,088h,009h,06Fh
DB 0DFh,06Ch,045h,0F0h
DB 026h,0DFh,01Bh,03Ch
DB 009h,032h,0E0h,005h
DB 0C5h,045h,0BCh,0CAh
DB 078h,0C7h,0F8h,027h
DB 0D1h,009h,0ADh,08Bh
DB 0B3h,0AEh,03Fh,07Eh
DB 06Eh,073h,05Ah,0B1h
DB 021h,05Ah,016h,08Bh
DB 08Dh,0B0h,0C1h,047h
DB 05Eh,0f1h,0D9h,0E8h
DB 0F0h,02Eh,067h,014h
DB 0C0h,0BBh,057h,08Bh
DB 0BFh,0C8h,02Dh,046h
DB 035h,024h,06Ah,037h
DB 0DAh,092h,0D6h,0F9h
DB 0F7h,06Ch,0E2h,052h
DB 0C2h,056h,098h,028h
DB 069h,083h,00Ch,004h
DB 005h,03Dh,065h,0C7h
DB 02Eh,0D0h,024h,0BDh
DB 051h,00Bh,043h,07Bh
DB 083h,04Ah,0BFh,06Ah
DB 0ECh,0A7h,080h,090h
DB 01Bh,006h,09Bh,0E8h
DB 028h,0B1h,0F4h,015h
DB 0DCh,07Fh,0C1h,091h
DB 076h,044h,01Ah,06Ch
DB 0BFh,01Eh,0FDh,0F0h
DB 013h,0F5h,0C1h,08Dh
DB 006h,0E1h,080h,0ACh
DB 06Dh,02Fh,07Fh,034h
DB 044h,0f2h,03Eh,0C9h
DB 0F9h,089h,0A7h,052h
DB 09Ah,05Dh,0D9h,07Fh
DB 0A0h,0EAh,002h,0A4h
;*****************************************************************/
;************* End of $Workfile: DES.A51 $ ************************/
;*****************************************************************/
This is a basic Hash function used in many smart card systems. This implementation is in Java
is used for electronic data signature. The source is a well known smart card vendor.
import java.awt.*;
import java.applet.*;
import java.io.*;
Message(){
for (int i=0; i<1024; i++) m[i]=0;}
}
sha() {
a = 0x67452301;
b = 0xefcdab89;
c = 0x98badcfe;
d = 0x10325476;
e = 0xc3d2e1f0;}
sha(String mot) {
int len,i;
Message input = new Message();
len = mot.length()+1;
i=(len / 4);
if (i*4<len) i++;
input.ml=i;
a = 0x67452301;
b = 0xefcdab89;
c = 0x98badcfe;
d = 0x10325476;
e = 0xc3d2e1f0;
this.SHAUpdate(input, len);
}
for (i=0;i<=input.ml-16;i+=16) {
for (j=0; j<16; j++) buffer[j]=input.m[i+j];
this.SHATransform(buffer);}
for(i=0;i<20;i++) old.FF(W[i]);
for(i=20;i<40;i++) old.GG(W[i]);
for(i=40;i<60;i++) old.HH(W[i]);
for(i=60;i<80;i++) old.II(W[i]);
a += old.a;
b += old.b;
c += old.c;
d += old.d;
e += old.e;
}
( Loop eight times ) Of course, it's only authentication, so it should be exportable for
( Load key into first 16 the usual boring reasons.
bytes of input )
code
This code derived from a leaked document from the GSM
standards. Some missing pieces were filled in by reverse-
engineering a working SIM. We have verified that this is the
( Perform substitutions )
for
correct COMP128 algorithm.
for
code
Telex: 847152
( At this stage the vector x[] Note: There are three typos in the spec (discovered by
reverse-engineering).
consists of 32 nibbles.
The first 8 of these are taken as
the output SRES. )
The remainder of the code is not First, "z = (2 * x[n] + x[n]) mod 2^(9-j)"
given explicitly in the
standard, but was derived by
reverse-engineering.
should clearly read
for
"z = (2 * x[m] + x[n]) mod 2^(9-j)".
code
Second, the "k" loop in the "Form bits from bytes" section is
for severely botched: the k index should run only from 0 to 3, and
code clearly the range on "the (8-k)th bit of byte j" is also off (should
be 0..7, not 1..8, to be consistent with the subsequent section).
code
Third, SRES is taken from the first 8 nibbles of x[], not the last 8
as claimed in the document. (And the document doesn't specify how Kc is derived, but that
was also easily discovered with reverse engineering.)
#include <stdio.h>
/* #define TEST */
/*
* rand[0..15]: the challenge from the base station
* key[0..15]: the SIM's A3/A8 long-term key Ki
* simoutput[0..11]: what you'd get back if you fed rand and key to a real
* SIM.
*
* The GSM spec states that simoutput[0..3] is SRES,
* and simoutput[4..11] is Kc (the A5 session key).
* (See GSM 11.11, Section 8.16. See also the leaked document
* referenced below.)
* Note that Kc is bits 74..127 of the COMP128 output, followed by 10
* zeros.
* In other words, A5 is keyed with only 54 bits of entropy. This
* represents a deliberate weakening of the key used for voice privacy
* by a factor of over 1000.
*
* Verified with a Pacific Bell Schlumberger SIM. Your mileage may vary.
*
* Marc Briceno <marc@scard.org>, Ian Goldberg <iang@cs.berkeley.edu>,
* and David Wagner <daw@cs.berkeley.edu>
*/
int i;
int j;
int k;
int l;
int m;
int n;
int y;
int z;
int next_bit;
{
/* ( Load key into first 16 bytes of input ) */
for (j=0; j<16; j++)
{
x[j] = key[j];
}
/* ( Perform substitutions ) */
for (j=0; j<5; j++)
{
for (k=0; k<(1<<j); k++)
{
for (l=0; l<(1<<(4-j)); l++)
{
m = l + k*(1<<(5-j));
n = m + (1<<(4-j));
y = (x[m]+2*x[n]) % (1<<(9-j));
z = (2*x[m]+x[n]) % (1<<(9-j));
x[m] = table[j][y];
x[n] = table[j][z];
{
xsbit[4*j+k] = (x[j]>>(3-k)) & 1;
if (i < 8)
{
for (j=0; j<16; j++)
{
x[j+16] = 0;
{
next_bit = ((8*j + k)*17) % 128;
x[j+16] |= xsbit[next_bit] << (7-k);
}
}
/*
* ( At this stage the vector x[] consists of 32 nibbles.
* The first 8 of these are taken as the output SRES. )
*/
{
simoutput[i] = (x[2*i]<<4) | x[2*i+1];
}
{
simoutput[4+i] = (x[2*i+18]<<6) | (x[2*i+18+1]<<2)
| (x[2*i+18+2]>>2);
}
simoutput[4+6] = (x[2*6+18]<<6) | (x[2*6+18+1]<<2);
simoutput[4+7] = 0;
}
#ifdef TEST
int hextoint(char x)
{
key[i] = (hextoint(argv[1][2*i+2])<<4)|
hextoint(argv[1][2*i+3]);
rand[i] = (hextoint(argv[2][2*i+2])<<4) |
hextoint(argv[2][2*i+3]);
}
A3A8(key, rand, simoutput);
printf("simoutput: ");
for (i=0; i<12; i++)
{
printf("%02X", simoutput[i]);
printf("\n");
return 0;
}
#endif
Applied Cryptography 2nd Ed By Bruce Schneier pub 1996 by Wiley ISBN 0-471-
11709-9 NOTE US citizens may also obtain a companion CD containing electronic versions of
most of the ciphers in the book. The is THE reference for cryptography for the average
person.
Smart Card Handbook 2nd Ed. By Wrankel & Effing Pub 1999 by Wiley. ISBN 0-471-
98875-8 This is THE smart card reference book. Note the 2nd Edition in English is the 3rd
Edition of the original German version.
ISO 7816 parts 1-9 Design and use of Identification cars having
Integrated circuits with contacts, 7816 part 4 is the most intresting one for sw
engineers