PB173 - Tématický vývoj aplikací v C/C++
(Podzim/Fall 2014)
Domain specific development in C/C++
Skupina: Aplikovaná kryptografie a bezpečné programování
https://is.muni.cz/auth/predmety/uplny_vypis.pl?fakulta=1433;obdobi=618
4;predmet=788705
Petr Švenda svenda@fi.muni.cz
Konzultace: A406, Pondělí 15-15:50
PB173
Teams
• 2-3 persons
• Joint work, but every one presents its contribution
– Presentation on next seminar
• Form the teams now!
– TODO teams
2
"Theme" project
• Secure videoconferencing architecture
PB1733
PB173
"Theme" project – some details
• Users obtains certificate of identity from
Certification authority
• Users register with Videoconferencing server
• Videoconferencing server provides list of connected
users, help to establish video connection and
charge fee based on call length
• Client maintains user identity, related keys and
provides high speed encryption of audio/video
stream
4
Practical assignment
• Design and document API to:
1. new user registration
2. user authentication to server
3. obtain list of other users
4. establish secure channel to other (online) users (ENC, MAC)
5. exchange stream data with other user (audio only)
6. close secure channel
7. disconnect user from server
8. ...?
• Document functions in JavaDoc-style (Doxygen)
• CA/Client/Server are separate processes
– design communication over sockets or http requests
PB1735
Practical assignment – cont.
• Prepare document and presentation with design
decisions
– 2-3xA4 document (overview, functions, crypto used...)
– 4-5 slides (presentation)
• Your design will be presented and discussed next
week
PB1736
Designing good API, authenticated
encryption
PB1737
Principles of good API
1. Be minimal
2. Be complete
3. Have clear and simple semantics
4. Be intuitive
5. Be easy to memorize
6. Lead to readable code
• read more at e.g., http://doc.trolltech.com/qq/qq13-apis.html
• security API even harder:
http://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c18.pdf
• http://blog.apigee.com/taglist/security
PB1738
Read more about this topics
• Schneier on Security: http://www.schneier.com/
• TaoSecurity http://taosecurity.blogspot.com/
• Krebs on Security: http://krebsonsecurity.com/
• Freedom to Tinker: https://freedom-to-tinker.com/
• Light Blue Touchpaper:
http://www.lightbluetouchpaper.org/
• …
PB1739
Copy-free functions
• API style which minimizes array copy operations
• Frequently used in cryptography
– we take block, process it and put back
– can take place inside original memory array
• int encrypt(byte array[], int startOffset, int length);
– encrypt data from startOffset to startOffset + length;
• Wrong(?) example:
– int encrypt(byte array[], int length, byte outArray[], int*
pOutLength);
– note: C/C++ can still use pointers arithmetic
– note: Java can’t (we need to create new array)
PB17310
Block cipher modes for Authenticated
Encryption
PB17311
Modes for authenticated encryption
• Encryption preserves confidentiality but not integrity
• Common integrity functions (like CRC) protect
against random faults
• Cryptographic message integrity protects
intensional errors
PB17312
Confidentiality, integrity, privacy
• Message confidentiality [encryption]
– attacker is not able to obtain info about plaintext
• Message integrity [MAC]
– attacker is not able to modify message without being
detected (PTX, CTX)
• Message privacy [encryption]
– attacker is not able to distinguish between encrypted
message and random string
– same message is encrypted each time differently
PB17313
Encryption and MAC composition
• Modes for block ciphers (CBC, CTR, CBC-MAC)
• Compositions (encryption + MAC)
– encrypt-and-mac [EKe,Km(M) = EKe(M) | TKm(M)]
• can fail with privacy and authenticity
– mac-then-encrypt [EKe,Km(M) = EKe(M | TKm(M))]
• can fail with authenticity
– encrypt-then-mac [EKe,Km(M) = EKe(M) || TKm(EKe(M)]
• always provides privacy and authenticity
• Paralelizability issue
• Authenticated-encryption modes (AE)
– special block cipher modes for composed process
PB17314
Usage scenarios
• Powerful, parallelizable environments
– hardware accelerators
• Powerful, but almost serial environments
– personal computer, PDA
• Restricted environments
– smart card, cellular phone
• Different scenarios have different needs
PB17315
Important features for AE modes
• Provable security
• Performance, paralelizability, memory req.
– important for high-speed encryption, SC
• Patent
– early AE modes were patented
• Associated data authentication
– authentication of non-encrypted part
• Online, incremental MAC, number of keys, endian
dependency …
• http://blog.cryptographyengineering.com/2012/05/how-to-
choose-authenticated-encryption.html
• www.fi.muni.cz/~xsvenda/docs/AE_comparison_ipics04.pdf
PB17316
EAX mode
PB173
Encrypt-than-mac composition
Provable secure, unpatented
17
Offset CodeBook mode (OCB)
PB173
Memory efficient, fast mode
Provable secure, but patented
18
Cipher-State mode (CS)
PB173
Memory efficient, fast mode, unpatented
Not provable secure (inner state of cipher)
19
Galois/Counter Mode (GCM)
PB173
Need pre-computed table (4kB-64kB)
fast mode, provable secure, unpatented, NIST standard
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-
800-38D.pdf
20
Implementation: AES-GCM from PolarSSL
• gcm.h, gcm.c
PB173
int gcm_init( gcm_context *ctx,
const unsigned char *key,
unsigned int keysize );
int gcm_crypt_and_tag( gcm_context *ctx,
int mode, // GCM_ENCRYPT (alternatively GCM_DECRYPT)
size_t length,
const unsigned char *iv,
size_t iv_len,
const unsigned char *add, // authenticated, but not encrypted
size_t add_len,
const unsigned char *input, // authenticated and encrypted
unsigned char *output, // encrypted data
size_t tag_len,
unsigned char *tag );
int gcm_auth_decrypt( gcm_context *ctx,
size_t length, // length of input data
const unsigned char *iv,
size_t iv_len,
const unsigned char *add, // authenticated, but not encrypted
size_t add_len,
const unsigned char *tag, // authenticator (MAC value)
size_t tag_len,
const unsigned char *input, // encrypted data
unsigned char *output ); // decrypted data
21
CAESAR competition
• http://competitions.cr.yp.to/caesar-submissions.html
22 PB173
Conclusions
• Composition of ENC and MAC can fail
– encrypt-then-mac provable secure
– specially designed composed modes
• Most promising mode is patented (OCB)
– fast alternative GCM, CS
– Searching for new modes (CAESAR competition)
• Suitable mode depends on usage
– parallelizability, memory
– specific needs (online, incremental MAC)
PB17323