1 / 17

Requirements and suggestions for MICs

Requirements and suggestions for MICs. David McGrew Cisco Karl Norrman, Mats Näslund Ericsson. [mats.naslund@era.ericsson.se]. Confidentiality and Integrity. Serious flaws in WEP needs to be fixed. Confidentiality and integrity SHOULD be possible to use independently.

ivory
Download Presentation

Requirements and suggestions for MICs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements and suggestions for MICs David McGrewCiscoKarl Norrman, Mats NäslundEricsson [mats.naslund@era.ericsson.se] D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  2. Confidentiality and Integrity Serious flaws in WEP needs to be fixed. Confidentiality and integrity SHOULD be possible to use independently. - Flexible adaptation to various security needs and bandwidth/computational resources. - DoS on OCB (should first check MIC, then decrypt) - Regulatory/export control on encryption. D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  3. Existing TKIP Proposal [Ferguson]: The “Michael” MIC function + RC4 cipher Pros: Stand-alone MIC. Simple and fast. Claimed security, 20 bits: astronomically better than existing CRC. Cons: The security is only a claim based on heuristics and preliminary analysis. The (claimed) effective security is only  30% of the tag size  bandwidth “waste”. Uses decrypt-then-authenticate (DoS). Does not allow MIC without encryption (c.f. OCB). D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  4. Wegman-Carter Paradigm Definition: A family of functions { hk : A  B } is an -universal hash family if  x1 x2 A, c  B, Prk [ hk(x1) - hk(x2) = c]  . Theorem: An -U hash family gives a MIC, with forgery probability at most . Construction: Integrity key k specifies hk(x), MIC(k, x) = hk(x)  s, where s = RC4 output. D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  5. Hash-based MICs in 802.11 Simple, efficient -U hash  secure MIC. MMH [Halevi,Krawczyk] is a popular one. [Ferguson] rules out the MMH for 802.11: “...requires the use of a multiply instruction. This will not be implementable at any reasonable speed […], and it lacks the option of using tables to speed up the computations.” We think other choices deserves further study! D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  6. Core of MMH Key, S, and message, M, treated as sequence of t integers mod 2m, e.g. m = 16. MMH16 (S, M) = [S[i]M[i] mod (216 + 1) ] mod 216. Hard to beat on a Pentium class processor... There are alternatives which MAY be better suited for low-end devices. D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  7. t-1 V(S,M) = S[i]M[i] =  A[L[S[i]] + L[M[i]] mod 255] i=0 t-1 i=0 S[i], M[i]  0 can be eliminated Byte-oriented MMH Alternative Core function: V(S, M). t-byte message and sub-key, M, S, interpreted as elt’s in GF(28)t. L, A: 256-byte log/antilog tables. D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  8. Compression Function If data = D[0] || D[1] || … || D[n-1], D[i]  GF(28)8. C(S, D) = V(S, D[0]) || … || V(S, D[n-1]). ...and a tree-hash, a key for each level of the tree. D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  9. Hash Tree (one-byte tag) message C( , ) one 8-byte subkey per level C( , ) Hash(m) D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  10. Hash “Key Schedule” (1-byte tag) 0 1 2 3 … 9 10 ... Key, K L0 A0 A1 2-byte length mask one 8-byte subkey/level of tree D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  11. Hash Computation (1-byte tag) • Hash(K,M): /* K = L0 || A0 || A1 … */ • l len(M); /* 2 bytes */ • X  M; i  0; • while len(X) > 8 do • X  C(Ai, X); • i  i + 1; • end while • return V(L0, l)  V(Ai, X) To get T > 1 byte tag, use standard Toeplitz construction. D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  12. Key Sizes for T-byte Tags • MAX_MSG_LENGTH Key size • 8 7 + 3T • 64 14 + 4T • 512 21 + 5T • 4096 28 + 6T • 32768 35 + 7T D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  13. Security for T-byte Tags • MAX_MSG_LENGTH (bytes) Forgery prob. • 8 2-8T • 64 2-7T • 512 2-6.42T • 4096 2-6T • 32768 2-5.68T (Effective tag size typically  75 %, c.f. 30% for Michael) D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  14. Performance Highly preliminary figures (PIII 650, MS Visual C, 3-byte tag): “Short” messages: 632k tags/sec. “Long” messages: 22k tags/sec. (This is worse than MMH, but that’s expected on a PIII.) D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  15. Order of MIC and Encryption Currently, MIC is applied to plaintext, then encryption is performed. Drawback: - Reciever has to decrypt before checking MIC (DoS). - It’s established that it cryptographically better to encrypt first. (No extra plaintext redundancy.) D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  16. ke message tag  RC4, AES_CM, ... keystream MIC encrypted payload ka Prefix to reduce DoS Hash Based MIC in Practice KG Hash [IETF: draft-mcgrew-saag-ust-00.txt, draft-ietf-avt-srtp-03.txt] D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

  17. Summary and Open Issues Confidentiality and integrity SHOULD be independent. Order of MIC and encryption important. Michael basically “OK”, but think additional MICs deserve further study. Preliminary ideas for simple and security-robust constructions presented. To be done: Evaluate their performance on target HW/CPU. D. McGrew (Cisco); K. Norrman, M. Näslund (Ericsson)

More Related