A practical integrated device for low-overhead, secure communications.

Matt LewisGord Allan

Design GoalsDesign Goals

• VersatilityVersatility - can be used in a range of devices

- compatibility, low/no infrastructure

• MobilityMobility - low power consumption

• SecuritySecurity - 2048 bit RSA key exchange

- AES RC6 data exchange

- RSA based authentication

• ThroughputThroughput - 150 ms for RSA cycle

- 100+ Mbps RC6 throughput

Asymmetric Exchange of Symmetric KeyAsymmetric Exchange of Symmetric Key

• Use public key cryptography to agree on a mutual symmetric key for use in a symmetric cipher.

• Assume all public keys are known (falls apart later)

AB

encB(lets use k)

Asure

BencRC6(m)

.

.

.

Asymmetric Exchange of Symmetric KeyAsymmetric Exchange of Symmetric Key

VulnerabilitiesA

B

encB(lets use k)

A

sure

B

encRC6(m)

.

.

.

• Impersonation of origin

• Replay Attack

Additionally

• Public Key lookup

Key Exchange and Identity AuthenticationKey Exchange and Identity Authentication

Diffie-Hellman

Advantages:

- computational feasibility, small keys

- key agreement, resists replay attacks

Disadvantages:

- active intruder problem

- impractical solution, high overhead

Key Exchange and Identity AuthenticationKey Exchange and Identity Authentication

RSA

Advantages:

- message content can be controlled

- authentication is manageable

Disadvantages:

- highly computational (speed/power)

- requires specialized hardware (area)

User CertificatesUser Certificates

To solve impersonation and public key distribution attacks we rely on an authentication scheme which makes use of certificates.

101101001…1011010111011

AAssociated with a device we have:

• Extended IP / Phone Nbr (128 bit)• MAC (48 bit)• Control/Future Use (16 bit) • Public Key ‘n’ (2048 bit)

Certificate FormatCertificate Format

A certificate is 2560 bits and contains an encrypted version of A’s public data.

It is encrypted by the issuing authority’s private key on configuration of the device and saved into the chip’s EEPROM.

All devices can easily decode the certificate, but only the issuing authority can create a certificate.

Header IP/ID MAC Public Key - ‘N’ Footer

160 128 48 2048 16 160

Key Exchange ProtocolKey Exchange Protocol

Header IP/ID MAC Public Key - ‘N’ Footer

160 128 48 2048 16 160

Call ProtocolA B

• Calls B, knowing IP/ID

• Sends certificate CA

• prepares random 2047 bit key• Decodes CA (CA

F4 mod NIA)

• sends CB to A’s IP/ID

• prepares random 2047 bit key

• encodes SB = NbrBF4 mod NA

• sends SB to A

• decodes CB (CBF4 mod NIA)

• encodes SA = NbrAF4 mod NB

• sends SA to B

• decodes SA (SAd mod NB)

• keyRC6 = (NbrAXOR NbrB)1919-2047

• decodes SB (SBd mod NA)

• keyRC6 = (NbrBXOR NbrA)1919-2047

Additional ConsiderationsAdditional Considerations

• Certificate forgery

• Device configuration

• DNS/Phone lookup

• Compatibility

Certificate ForgeryCertificate Forgery

With the current signature scheme, the issuing authority (IA) is the only holder of the secret encryption key.

The IA then, is the only one with the ability to encode a given bit sequence.

It is possible for an imposter to generate a random bit string, and decode it to determine whether it meets the format requirements of a certificate. If it does, the intruder can intercept a call, and provide its forged certificate with a weak value of N, such that d can be factored out.

To prevent forgery, the header and footer of a certificate is composed of a set data sequence. This sequence must be matched to prove a certificate valid.

Certificate ForgeryCertificate Forgery

With a 160 bit header and footer the imposter would have to generate a block that when decrypted not only has a weak N but has to match 320 bits. The odds of a randomly generated block decrypting to this are approximately 2320 to 1. This is also assuming they can forge their IP and MAC address which is feasible.

So using this signature scheme each party can be pretty much be guaranteed that the signatures are authentic given that the trusted authority is secure.

Device ConfigurationDevice Configuration

The device is first configured in the factory. If the chip is part of a network card the MAC address for the card is put into the signature. This can also be done with mobile phones as they also carry a unique number that identifies them. Next the IP/ID field is set to a default zero. An N is then generated for the new chip and the signature is then encrypted with the constant header and footer. The decryption key is then programmedinto the chip. Now the device is ready for the real world.

One might note here that we have not discussed the encryption key. This is because it is always going to be F4 (Fermat’s prime = 216 +1). This will also be the case for decrypting signatures.

Header IP/ID MAC Public Key - ‘N’ Footer

160 128 48 2048 16 160

Device ConfigurationDevice Configuration

Once the chip is activated on a network for the first time it must contact the trusted authority to get a new signature that includes its new IP/Phone number. The trusted authority will maintain a database containing the MAC, IP, and N for each card. Upon a valid issue, the TA can update future lookup/ DNS servers.

The conversation with the trusted authority uses the same protocol described earlier but the TA verifies the old signature and generates a new one based on the requested IP address of the client. Upon receiving the new signature the client reprograms itself and is ready to go again. One thing to note here is by keeping a list of MAC and IP numbers one can verify that a client is not using an old signature.

DNS/Phone LookupDNS/Phone Lookup

The TA now is in the perfect position to act as a DNS/Phone server. This however would cause too much work for the TA, so a distributed approach is necessary. The TA can give up some of its power to allow DNS/Phone servers to have copies of the MAC/IP database. It does not however give away it’s secret key to encrypt signatures.

A DNS/Phone server must provide both the MAC/IP numbers to the client so that it can verify the other parties signature is up to date and valid. If the IP and MAC address don’t match it means the person is using an old signature.

This scheme allows the TA to only deal with new signatures which on phones will happen very rarely and when IPV6 takes over this will also be the case on the Internet.

RC6 Symmetric Key CipherRC6 Symmetric Key Cipher

Design Considerations:

- Simplicity

- Algorithm

- Implementation

- Analysis

- Performance

- Throughput

- Latency

- Security

RC6 Encryption AlgorithmRC6 Encryption Algorithm

RC6 Key ScheduleRC6 Key Schedule

-Simple

- No known “weak keys”(P(weak key) = 10-1152)

- Again based on RC5 key schedule (no know good attacks)

- Can’t generate round keys concurrently with encryption (+latency)

RC6 SecurityRC6 Security-RC6 design is based on RC5 with slight modification that hold off possible attacks

-Linear and differential attacks are no good on 20 round version

-Best way to crack RC6 is an exhaustive key search

-Best know attack on RC5 allows 12 rounds to be cracked in the long term

RC6 Symmetric Key CipherRC6 Symmetric Key Cipher

RC6 Simplicity:- Smallest memory requirement for code for Smart Cards (does requires small amount of RAM for data)- Extremely easy to code in software

Performance Results:- Fastest remaining AES candidate on both Intel and Alpha CPU’s- Excellent performance with ASIC design- Good performance on 8 bit CPU’s and FPGA’s (3rd)

Security:- Excellent (Lots on RC5)- Easy to do a thorough analysis on how secure it is

Future Expandability:- The algorithm can be easily modified to a 256 bit block cipher that uses 64 bit blocks in encryption/decryption

Block Overview of ChipBlock Overview of Chip

Random Bit GeneratorRandom Bit Generator

Modular Exponentiation: Modular Exponentiation: P = XE mod N

Montgomery’s Algorithm:

Po = 1, Zo = Xfor i=0 to n-1 do

Zi+1 = Zi2 mod N

if ei = 1 then Pi+1 = Pi*Zi mod N

Where: Zi is a 2048 bit partial productPi is a 2048 bit partial product

Storage: 2*Z + 2*P + N + E = 12288 bitsWork: Avg: 1.5*ne modular multiplies

• reduce the exponentiation into up to 2*ne 2048 bit modular multiplications

• reduce each modular multiplication into n/u (2560/32) discrete operation with carries

Modular Multiplication: A*B mod N

Ro = 0for i=0 to n+2

qi = Ri(0)

Ri+1=(Ri + ai • B + qi•N)/2

B = 0101 1101 1011* A = 1011 0110 0110

0000 0000 0000+ 0101 1101 1011+ 0101 1101 1011etc...

Proposed Architecture: Thomas BlumProposed Architecture: Thomas Blum

P = XE mod N

Po = 1, Zo = Xfor i=0 to n-1 do

Zi+1 = Zi2 mod N

if ei = 1 then Pi+1 = Pi*Zi mod N

Proposed Architecture: Thomas BlumProposed Architecture: Thomas Blum

A Systolic array for 2048/2560 bit modular multiplication.• N=2560, u=32bit• 80 units

Ri+1=(Ri + ai • B + qi•N)/2

B = 0101 1101 1011* A = 1011 0110 0110

0000 0000 0000+ 0101 1101 1011+ 0101 1101 1011etc...

Proposed Architecture:Proposed Architecture:

Architecture of a single cell to compute u bits:

Ri+1=(Ri + ai • B + qi•N)/2

B = 0101 1101 1011* A = 1011 0110 0110

0000 0000 0000+ 0101 1101 1011+ 0101 1101 1011etc...

RSA Hardware Estimates and SpecificationsRSA Hardware Estimates and Specifications

Memory: 197 bits/unit*80 + 4*2048 = 23952 bits

Area: 2.9x2.9 mm2 (12u*20u*23952*1.5)- would need more for IO pads

Encode/Verify Time: 2 ms, using F4=216+1

Decode Time: 160-180ms: u=32, n=2560; (2560/512)2 * t512

Power: 0.25*197*80*3uW/Mhz*35Mhz = 413mW@ 3.6 V --> Draws 115 mA avg, 700 mA peak

RC6 HardwareRC6 Hardware

Design Goals:

- Faster than software implementation

- Low power

- Small die area

RC6 Hardware Requirements:

- Multiplier(?) B(2B+1) => 2B2+B

- Variable bit shifter

- Adders, registers, and XOR blocks

- 0.35u or 0.25u process technology

Squaring HardwareSquaring Hardware

RC6 HardwareRC6 Hardware

RC6 Hardware SummaryRC6 Hardware Summary

Estimated Performance:

- >100 Mbps throughput @ 20 MHz

- Easily increased w/ pipelining or Loop Unrolling

- <50us latency on first block

Estimated Power Requirements:

- RC6 cipher @ 20 MHz ≅ 24mW + I/O Power

Estimated Die Area:

- RC6 cipher ≅ 1mm2

- RC6 key scheduler and key storage ≅ 1mm2

ConclusionConclusion

Performance: Call setup time < 200 ms

RC6 throughput > 100 Mbps

Power Requirements: RC6 cipher ≅ 24mW

Die Area: RSA + RC6 cipher ≅ 3.3 x 3.3 mm

Security: 2048 bit RSA Key exchange

User authentication

128 bit RC6 AES candidate

Work in progress: VHDL encoding, simulation and synthesis

Interface specifications

Thank you for your attention.