Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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.