P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\titulka.jpg PA193 - Secure coding principles and practices Protecting integrity of modules and external components •Petr Švenda svenda@fi.muni.cz • P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Overview •Lecture: –dynamic libraries, forging, protection –code signing –temporary files –protections in whitebox attacker model •Labs –Projects defense 2 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg PROBLEM • 3 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg • 4 PA193 | Integrity of modules Application binary Local I/O Remote I/O Running application Temporary files Configurations (registry, files) Dynamic libraries Secure element Server application P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg DYNAMIC LIBRARIES • 5 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg PA193 | Integrity of modules Dynamic library usage (Windows) •Static linking –library.lib added to dependencies •Run-time dynamic linking –controllable run-time search for dynamic library –developer can control and respond on (un)available lib –LoadLibrary(path) & FreeLibrary(hLib) •Run-time search for specific function –GetProcAddress(hLib, “function_name”) –cast to target function prototype (later) 6 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Default order of directory search for DLL 1.The directory from which the application loaded –“application directory” 2.The system directory 3.The 16-bit system directory 4.The Windows directory 5.The current directory 6.The directories that are listed in the PATH environment variable •Safe DLL search mode place current directory to 5. 7 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg DLL preloading attack •Called DLL preloading or binary planting attack 1.Attacker obtains write access to one directory in search list 2.Attacker places malicious DLL here 3.If application will not find DLL in directories searched before, attacker’s DLL gets loaded 4.Malicious code is executed with application privileges 8 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg How to execute man-in-the-middle for dll •Application wants to load dynamic library –according to specified name, e.g., winscard.dll –e.g. via LoadLibrary(“winscard.dll”) call •Create dynamic library (“stub”) with the same name and the same set of exported functions •Move stub DLL into directory where application looks first for requested DLL –stub is loaded instead of original –application will call stub function instead •When given function from stub is called, pass input arguments to the original DLL and return response –or modify, log, delay, block... 9 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Example: APDUPlay •Dynamic library for interception and manipulation of communication with smart cards –winscard.dll, APDU-based communication –http://www.fi.muni.cz/~xsvenda/apduinspect.html •What you can achieve: –log input/output APDU commands (including keys, PINs...) –manipulate APDUs content according to predefined rules •e.g., return OK even when verification fails •e.g., simulate presence of reader / smart card –reverse engineer protocol used based on communication –redirect communication to other computer via socket • 10 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Let’s write own winscard.dll (PC/SC) PA193 | Integrity of modules User application winscard.dll (stub) original.dll [begin] SCardTransmit (handle 0xEA010001)# apduCounter:0# totalBytesINCounter:1# transmitted:00 a4 04 00 0a a0 00 00 00 28 80 10 30 01 ff responseTime:31# SCardTransmit result:0x0# received:6a 81 SCardTransmit (handle 0xEA010001)# apduCounter:1# totalBytesINCounter:16# … based on ApduView utility (by Fernandes) http://www.fi.muni.cz/~xsvenda/apduinspect.html 11 winscard.dll P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg DEMO: capturing PIN from GPG •Smart card with OpenPGP applet –communication is realized via winscard.dll •gpg2 --card-edit –gpg/card> verify •PIN is visible in captured log • – 12 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg How to load proper library? 1.Use fully qualified path to load library (LoadLibrary) 2.Dynamic-Link Library Redirection –https://tinyurl.com/chy5wum –redirection file is created in application directory –App_name.local (e.g., explorer.exe ® explorer.exe.local) •(content of file is ignored) –application directory is searched first for the target DLL –good practice to install application DLLs in its directory •will not overwrite other versions of same DLL –(will not work if application has manifest) – • 13 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg How to load proper library? (2) 3.Application manifest –XML file with various application configurations –including versions and hash (SHA-1) of required DLLs –when required DLL is loaded, hash is checked –https://tinyurl.com/b2dz8u9 – 14 PA193 | Integrity of modules ... ... P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg PA193 | Integrity of modules Security implications of dynamic libraries •Library can be forged and exchanged •Library-in-the-middle attack easy –data flow logging –input/output manipulation •Library outputs can be less checked then user inputs –feeling that library is my “internal” stuff and should play by „my“ rules •Library function call can be behind logical access controls 15 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg References •Dynamic-Link Library Security –http://msdn.microsoft.com/en-us/library/windows/desktop/ff919712%28v=vs.85%29.aspx •Assembly manifests –http://msdn.microsoft.com/en-us/library/aa374219%28v=vs.85%29.aspx •Assembly signing example –http://msdn.microsoft.com/en-us/library/aa374228%28v=vs.85%29.aspx – • 16 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg CODE SIGNING • 17 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg PA193 | Integrity of modules Code authenticity •Why to authenticate binary/source codes? –random transmission errors solved by transport layer (CRC) –intentional modification on remote code repository –intentional modification during transport (MITM) –intentional modification locally (malware in user space) –NSA Bullrun program... •Strong authentication often required implicitly –relatively restricted platforms like iOS / Android... –kernel drivers (no unsigned kernel driver from Vista 64bit) –official software repositories… 18 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Possibilities for code signature 1.Non-keyed hash function sign = H(your_package) –everyone can compute H(modified_package) –where to get “correct” hash value? (usually same webpage L) –often MD5 algorithm (known collisions, insecure) –often need for manual verification (lazy users) 2.Authentication based on symmetric cryptography –keyed MAC, sign = HMAC(key, your_package) –not suitable for one to many distribution (shared key) 3.Authentication based on asymmetric cryptography –digital signatures of package sign = RSA(private_key, your_package) –everybody can Verify(public_key, sign) –most suitable, but may require PKI (trust to public key is critical) 19 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Code signing (GPG/PGP) •PGP/GPG can be used for code signing –same process as message signature –signature is usually detached into separate file (*.sig) • • •Trust to signing key is needed –public key should be obtained from trusted source –but usually only publisher website or keyserver L •Can be used to sign packages (e.g., Debian RPM) –http://fedoranews.org/tchung/gpg/ 20 PA193 | Integrity of modules gpg --output app.sig --detach-sig app gpg --verify app.sig app P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Various code signing managers •Java certificates (also Android) –java-based applications and applets (.jar) •Microsoft Authenticode –Active-X controls, plug-ins, execs (.cab, .cat, .ctl, .ocx, .exe, .dll) •Adobe Air certificate –Adobe Ajax and flex files (.air and .airi) •Microsoft Office and VBA certificate –Microsoft Office macros and Visual Basic applications •Apple developer program –applications for iOS platform •Difference: local sign vs. additional check on server 21 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Code signing (Microsoft’s Authenticode) 1.Publisher obtains Code Signing Digital ID –X.509 certificate with public key signed by trusted authority –authority’s certificate imported in Trusted Publishers 2.Publisher creates code (application) 3.Publisher signs code with its private key 4.Application is distributed along with signature(s) 5.Application signature is verified, user is notified –invalid signature of application ® confirmation from user –invalid signature of driver ® no installation –(problem with legacy apps, non-compliant developers) •(RSA 2048bit with SHA-1) • 22 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg • 23 PA193 | Integrity of modules D:\codesigningpublishers.png P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Microsoft WHQL •Windows Hardware Quality Labs (WHQL) •Intended for kernel-mode binaries (drivers, dll) •WHQL-certified binaries can be distributed through the Windows Update program •Signature stored in catalog file (*.cat) •Practical Windows Code and Driver Signing –http://www.davidegrayson.com/signing/ – • 24 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Microsoft Authenticode – selfsign (testing) •Process of creating Authenticode selfsign certificate –used for testing purposes –your certificate imported as Trusted Publisher –signing of exe, dll, scripts •http://msdn.microsoft.com/en-us/library/office/aa140234%28v=office.10%29.aspx • •Why it will not work for other computers? • 25 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Signed code == secure code? •Developer can sign anything –additional layer of validation of application needed •Microsoft WHQL, Google Play, Apple App Store... –but his/her key (and apps) can be revocated •Trusted authority can be compromised –Comodo, DigiNotar... •Signature must be verified correctly –Android Master key vulnerability –https://tinyurl.com/kj63ae8, https://tinyurl.com/p5fu3j3 •Signed application can execute unsigned code –Apple's Nitro JavaScript engine, https://tinyurl.com/6tpvzpq 26 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg TEMPORARY FILES • 27 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Why we use temporary files? •Temporary files are used only during the program run –no persistence between runs is typically assumed •Used to offload (large) data from memory to disk –too large to fit into memory of the application •Communication with other process –transferring data through the file system • 28 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Creating temporary files in C/C++ •FILE* tmpfile (void); –creates new temporary binary file with unique file name and opens it for update (“wb”) –file is created in TMP directory according to environment settings –file is automatically closed at program end (including crash) •char* tmpnam (char * str); –return unique file name not used yet (but is not opening file) –additional call to fopen() is required –if not specified, file is created in current directory –Warning: file is not opened in the same time, attacker can open it and manipulate in between – Race condition –tmpnam generates a different string each time you call it, up to TMP_MAX times (defined in stdio.h as 65,535) – • 29 PA193 | Integrity of modules #include P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Creating temporary files in C/C++ (2) •Function alternatives from Secure C library exist –secure from the perspective of buffer manipulation –not necessarily against various attacks described later •errno_t tmpnam_s(char *s, rsize_t maxsize); –returns unique file name (same format as tmpnam) •errno_t tmpfile_s(FILE*restrict*restrict streamptr) –creates new temporary binary file with unique file name and opens it for update (“wb”) –NOTE: if program crashes, tmp file might NOT be removed (difference to tmpfile) – – 30 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Removing temporary files in C/C++ •_rmtmp() –removes all temporary files created by tmpfile / tmpfile_s –NOTE: will leave invalid FILE* handle(s) •Files created by tmpfile / tmpfile_s –fclose() will remove the file –normal program termination will remove the file –abnormal program termination might not remove files •Temporary files opened by tmpnam() & fopen() –not treated by system as temporary files –developer is responsible for removal • 31 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Problem with temporary files - TOCTOU • 32 PA193 | Integrity of modules #include int main() { const size_t BUFFER_SIZE = 1000; char filename[BUFFER_SIZE]; // Get unique file name tmpnam_s(filename, BUFFER_SIZE); // Test if no such file exists FILE *fp = fopen(filename,"r"); if( !fp ) { // file does not exist fp = fopen(filename,"w"); // use tmp file... fclose(fp); } else { // file exists, go for other name fclose(fp); } return 0; } attacker can open filename during this period (TOCTOU) Time Of Check Time Of Use P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Problem with temp. files - predictability • 33 PA193 | Integrity of modules #include #include int main(int argc, char* argv[]) { const size_t BUFFER_SIZE = 1000; const size_t NUM_FILES = 15; char buffer[BUFFER_SIZE]; // Obtain directory for temporary files GetTempPath(BUFFER_SIZE, buffer); printf("Temporary directory: %s\n", buffer); FILE * pFile1[NUM_FILES]; // Obtain unique file name for (size_t i = 0; i < NUM_FILES; i++) { tmpnam_s(buffer, BUFFER_SIZE); printf("Unique file name: %s\n", buffer); fopen_s(&pFile1[i], buffer + 1, "wb"); } return 0; } Temporary directory: C:\Users\petr\AppData\Local\Temp\ Unique file name: \s4sg. Unique file name: \s4sg.1 Unique file name: \s4sg.2 Unique file name: \s4sg.3 Unique file name: \s4sg.4 Unique file name: \s4sg.5 Unique file name: \s4sg.6 Unique file name: \s4sg.7 Unique file name: \s4sg.8 Unique file name: \s4sg.9 Unique file name: \s4sg.a Unique file name: \s4sg.b Unique file name: \s4sg.c Unique file name: \s4sg.d Unique file name: \s4sg.e P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Problem with temp. files – predictability (2) • 34 PA193 | Integrity of modules #include int main(int argc, char* argv[]) { const size_t NUM_FILES = 15; FILE * pFile2[NUM_FILES]; // Open temporary files for (size_t i = 0; i < NUM_FILES; i++) { tmpfile_s(&pFile2[i]); } // Wait - tmp files can be spotted in tmp directory getchar(); // Remove tmp files (only these opened by tmpfile / tmpfile_s) // Handles FILE* inside pFile2 now have invalid value _rmtmp(); return 0; } 06/11/2013 15:28 0 t3oc 06/11/2013 15:28 0 t3oc.1 06/11/2013 15:28 0 t3oc.2 06/11/2013 15:28 0 t3oc.3 06/11/2013 15:28 0 t3oc.4 06/11/2013 15:28 0 t3oc.5 06/11/2013 15:28 0 t3oc.6 06/11/2013 15:28 0 t3oc.7 06/11/2013 15:28 0 t3oc.8 06/11/2013 15:28 0 t3oc.9 06/11/2013 15:28 0 t3oc.a 06/11/2013 15:28 0 t3oc.b 06/11/2013 15:28 0 t3oc.c 06/11/2013 15:28 0 t3oc.d 06/11/2013 15:28 0 t3oc.e P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Problems with creating tmp files (MSVC) •tmpnam() / tmpnam_s() –format as sxxx.# –TOCTOU •tmpfile() / tmpfile_s() –unique file name is generated as txxx.# where xxx is digit or character and # is sequential number or character –predictability •Attacker can: –predict file name, create own file (TOCTOU) –then capture sensitive & forge malformed data – 35 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Temporary files in Java •File tempFile = File.createTempFile(prefix, suffix); –Will keep file even when JVM exits –Longer name then in C/C++ (by default) •Ask for delete on JVM exit –tempFile.deleteOnExit(); –But deleted only during “normal” termination –“Deletion will be attempted only for normal termination of the virtual machine, as defined by the Java Language Specification.” •Similar problems as for C/C++ 36 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg TEMPORARY FILES – SECURITY CHECKLIST • 37 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Temporary files security checklist 1.Avoid temporary files if possible J 2.Don’t use standard C function for temporary files –mktemp(), tmpnam(), tempname(), tmpfile()... –predictable names, race conditions 3.Don’t store sensitive information in temp files –temp files are common attack vector, prevent it 4.Research where are temporary files stored –no standard function for that in C/C++ –Windows: GetTempPath() 38 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Temporary files security checklist (2) 5.Ensure strong uniqueness and unpredictability for name of temporary file –don’t use tmpnam or tmpfile functions (predictable) –generate long random name internally, open it, check –use strong random generating function like CAPI’s CryptGenRandom(), OpenSSL’s RAND_bytes()... • • 39 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Temporary files security checklist (2) 6.Ensure proper permissions for temporary file –avoid publically writable directories if possible –if publically writable directory is used, create subdirectory and set ACL’s (read and write) only for your application 7.Encrypt log file content with random key –generate random secret key every time you run your application –encrypt data before writing into log file (and decrypt when reading) –when program is abnormally terminated, (encrypted) temporary file will stay but random key will is lost –attacker cannot supply older temporary version (different key) 40 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Temporary files security checklist (3) 8.Perform secure cleanup –overwrite content of temporary file with random data before close •even when performing log file encryption (key may leak in memory dump, pagefile etc.) –leave no temporary files behind •close temporary files as soon as possible •call _rmtmp() if standard C functions were use for open –still possible to leave temporary files during abnormal termination •utilize own signal handlers •wrap main into big exception handler and cleanup – • 41 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Temporary files security checklist (4) 9.Rely on absolute, not on relative paths –relative paths will change when application current directory change –if user provides directory path for temporary files, sanitize it –use file handles (e.g., FILE*) instead of file path (TOCTOU) 10.Open files exclusively and non-existing only –C99: fopen(“filename”, “wb”) opens new as well as existing file L –C11: new exclusive create-and-open mode ("…x") for fopen –POSIX: open() with O_CREAT|O_EXCL –WIN32 API:CreateFile() with CREATE_NEW 42 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Example: (virtual LABs) •obtain temporary directory •create subdirectory, set proper ACL •generate long random file name •open file exclusively with absolute path •generate random key •encrypt data before write •shred content (overwrite) before close •close after use •handle abnormal termination (signal, exception) 43 PA193 | Integrity of modules D:\Documents\Obrázky\services_icon_full_bw5.jpg P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg References •Security Tips for Temporary File Usage in Applications –http://www.codeproject.com/Articles/15956/Security-Tips-for-Temporary-File-Usage-in-Applicat •FIO43-C. Do not create temporary files in shared directories –https://www.securecoding.cert.org/confluence/display/seccode/FIO43-C.+Do+not+create+temporary+file s+in+shared+directories •MITRE CWE-377: Insecure temporary files –http://cwe.mitre.org/data/definitions/377.html • • 44 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg OBFUSCATION, PROTECTING SOFTWARE MODULES • 45 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Standard vs. whitebox attacker model 46 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Standard AES API (PolarSSL) • 47 PA193 | Integrity of modules /** * \brief AES key schedule (encryption) * * \param ctx AES context to be initialized * \param key encryption key * \param keysize must be 128, 192 or 256 * * \return 0 if successful, or POLARSSL_ERR_AES_INVALID_KEY_LENGTH */ int aes_setkey_enc(aes_context *ctx, const unsigned char *key, unsigned int keysize); /** * \brief AES-ECB block encryption/decryption * * \param ctx AES context * \param mode AES_ENCRYPT or AES_DECRYPT * \param input 16-byte input block * \param output 16-byte output block * * \return 0 if successful */ int aes_crypt_ecb( aes_context *ctx, int mode, const unsigned char input[16], unsigned char output[16] ); P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Standard AES - usage • 48 PA193 | Integrity of modules void simpleAES() { unsigned char key[32]; unsigned char buf[16]; aes_context ctx; memset( buf, 1, sizeof(buf)); memset( &ctx, 0, sizeof(ctx)); // Set the key sprintf((char*)key, "%s", "SecurePassword:nbu123"); aes_setkey_enc( &ctx, key, 128); printf("Input: "); for (int i = 0; i < AES_BLOCK_SIZE; i++) printf("%2x", buf[i]); printf("\n"); // Encrypt one block aes_crypt_ecb( &ctx, AES_ENCRYPT, buf, buf ); printf("Output: "); for (int i = 0; i < AES_BLOCK_SIZE; i++) printf("%x", buf[i]); } P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg OllyDbg – key value is static string 49 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg OllyDbg – key is visible in memory 50 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg What if AES usage is somehow hidden? 51 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Whitebox attacker model •The attacker is able to: –inspect and disassemble binary (static strings, code...) –observe/modify all executed instructions (OllyDbg...) –observe/modify used memory (OllyDbg, memory dump...) •How to still protect value of cryptographic key? •Who might be white-box attacker? –Mathematician (for fun) –Security researcher / Malware analyst (for work) –DRM cracker (for fun&profit) –... – – • 52 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Classical obfuscation and its limits •Time-limited protection •Obfuscation is mostly based on obscurity –add bogus jumps –reorder related memory blocks –transform code into equivalent one, but less readable –pack binary into randomized virtual machine –... •Barak’s (im)possibility result (2001) –family of functions that will always leak some information –but practical implementation may exists for others • 53 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg CEF&CED •Computation with Encrypted Data and Encrypted Function 54 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Scenario •We’d like to compute function F over data D –secret algorithm F or sensitive data D (or both) •Solution with trusted environment –my trusted PC, trusted server, trusted cloud… •Problem: can be cloud or client really trusted? –server hack, DRM, malware... •Attacker model –controls execution environment (debugging) –sees all instructions and data executed PA193 | Integrity of modules 55 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg CEF •Computation with Encrypted Function (CEF) –A provides function F in form of P(F) –P can be executed on B’s machine with B’s data D as P(D) –B will not learn function F during computation • • • • PA193 | Integrity of modules A B 56 > P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg CED •Computation with Encrypted Data (CED) –B provides encrypted data D as E(D) to A –A is able to compute its F as F(E(D)) to produce E(F(D)) –A will not learn D PA193 | Integrity of modules A B 57 > P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg CED via homomorphism 1.Convert your function into circuit with additions (xor) and multiplications (and) only 2.Compute addition and/or multiplication “securely” –an attacker can compute E(D1+D2) = E(D1)+E(D2) –but will learn neither D1 nor D2 3.Execute whole circuit over encrypted data •Partial homomorphic scheme –either addition or multiplication is possible, but not both •Fully homomorphic scheme –both addition and multiplication (unlimited) PA193 | Integrity of modules 58 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Partial homomorphic schemes •Example with RSA (multiplication) –E(d1).E(d2) = d1e . d2e mod m = (d1d2)e mod m = E(d1d2) •Example Goldwasser-Micali (addition) –E(d1).E(d2) = xd1r12 . Xd2r22 = xd1+d2(r1r2)2 = E(d1Åd2) •Limited to polynomial and rational functions •Limited to only one type of operation (mult or add) –or one type and very limited number of other type •Slow – based on modular mult or exponentiation –every operation equivalent to whole RSA operation PA193 | Integrity of modules 59 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Fully homomorphic scheme (FHE) •Holy grail - idea proposed in 1978 (Rivest et al.) –both addition and multiplication securely •But no scheme until 2009 (Gentry)! –based on lattices over integers –noisy FHE usable only to few operations –combined with repair operation PA193 | Integrity of modules 60 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Fully homomorphic scheme - usages •Outsourced cloud computing and storage (FHE search) –Private Database Queries –using Somewhat Homomorphic Encryption http://researcher.ibm.com/researcher/files/us-shaih/privateQueries.pdf –protection of the query content •Secure voting protocols (yes/no + sum) •Protection of proprietary info - MRI machines –very expensive algorithm analyzing MR data, HW protected –central processing restricted due to processing of private patient data •Read more about current state of FHE –http://www.americanscientist.org/issues/id.15906,y.2012,no.5,content.true,page.2,css.print/issue.a spx – • • 61 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Fully homomorphic scheme - practicality •Not very practical (yet J) (Gentry, 2009) –2.7GB key & 2h computation for every repair operation –repair needed every ~10 multiplication •FHE-AES implementation (Gentry, 2012) –standard PC Þ 37 minutes/block (but 256GB RAM) • 62 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg WHITEBOX CRYPTOGRAPHY •Computation with Encrypted Data and Encrypted Function 63 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg White-box attack resistant cryptography •Problem limited from every cipher to symmetric cryptography cipher only –protects used cryptographic key (and data) •Special implementation fully compatible with standard AES/DES… 2002 (Chow et al.) –series of lookups into pre-computed tables •Implementation of AES which takes only data –key is already embedded inside –hard for an attacker to extract embedded key PA193 | Integrity of modules 64 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg PA193 | Integrity of modules Whitebox transform 65 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Impractical solution • • • • • • • • •Secure, but 2128 x 16B memory storage PA193 | Integrity of modules 00…00…00 00…00…01 00…01…11 11…11…11 01…11…11 … … 10…01…11 10…11…01 01…11…11 10…00…10 01…10…00 … … 2128 Input block Output block = AES(input, keyX) Precomputed table 66 2128 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg WBACR AES – some techniques •Pre-compute table for all possible inputs –practical for one 16bits or two 8bits arguments table with up to 216 rows (~64KB) –AddRoundKey: data Å key •8bit argument data, key fixed •Pack several operations together –AddRoundKey+SubBytes: T[i] = S[i Å key]; •Protect intermediate values by random bijections –removed automatically by next lookup –X = F-1(F(X)) –T[i] = S[F-1(i) Å key]; – PA193 | Integrity of modules 67 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Whitebox cryptography lifecycle •[Secure environment] 1.Generate required key (random, database...) 2.Generate WAES tables (in secure environment) •[Potential insecure environment] 3.Compile WAES tables into target application •[Insecure environment (User PC)] 4.Run application and use WAES as usual (with fixed key) 68 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg • PA193 | Integrity of modules makeTable() precompTable data encrypted data encrypt(data) AES key Environment under control of an attacker Environment outside control of an attacker 69 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Resulting implementation •More difficult to detect that crypto was used –no fixed constants in the code –precomputed tables change with every generation –even two tables for same key are different –(but can still be found) •Resistant even when precomputed tables are found –when debugged, only table lookups are seen –key value is never manipulated in plaintext –transformation techniques should provide protection to key embedded inside tables – 70 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg WBACR AES - pros •Performance is practically usable –implementation size ~800KB (tables) –speed ~MBs/sec (~6.5MB/s vs. 220MB/s) •Hard to extract embedded key –Complexity semi-formally guaranteed –(if the scheme is secure) •One can simulate asymmetric cryptography! –implementation contains only encryption part of AES –until attacker extracts key, decryption is not possible PA193 | Integrity of modules 71 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg WBACR AES - cons •Implementation can be used as oracle (black box) –attacker can supply inputs and obtain outputs –even if she cannot extract the key –(can be partially solved by I/O encodings) •Problem of secure input/output –protected is only AES, not code around •Key is fixed and cannot be easily changed •Successful cryptanalysis for several schemes –several former schemes broken –new techniques proposed •Fault induction attacks (2015, Riscure)! PA193 | Integrity of modules 72 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg List of proposals and attacks •(2002) First WB AES implementation by Chow et. al. [Chow02] –IO bijections, linear mixing bijections, external coding –broken by BGE cryptanalysis [Bill04] •algebraic attack, recovering symmetric key by modelling round function by system of algebraic equations •(2006) White Box Cryptography: A New Attempt [Bri06] –attempt to randomize whitebox primitives, perturbation & random equations added, S-boxes are enc. keys. 4 AES ciphers, major voting for result –broken by Mulder et. al. [Mul10] •removes perturbations and random equations, attacking on final round removing perturbations, structural decomposition. 217 steps •(2009) A Secure Implementation of White-box AES [Xia09] –broken by Mulder et. al. [Mul12] •linear equivalence algorithm used (backward AES-128 compatibility => linear protection has to be inverted in next round), 232 steps •(2011) Protecting white-box AES with dual ciphers [Kar11] –broken by our work [Kli13] •protection shown to be ineffective 73 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg More resources •Overviews, links –http://whiteboxcrypto.com/research.php –https://minotaur.fi.muni.cz:8443/~xsvenda/docuwiki/doku.php?id=public:mobilecrypto •Crackme challenges –http://www.phrack.org/issues.html?issue=68&id=8 •Whitebox crypto in DRM –http://whiteboxcrypto.com/files/2012_MISC_DRM.pdf – 74 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Whitebox transform IS used in the wild •Proprietary DRM systems –details are usually not published –AES-based functions, keyed hash functions, RSA, ECC... –interconnection with surrounding code •Chow at al. (2002) proposal made at Cloakware –firmware protection solution •Apple’s FairPlay & Brahms attack •http://whiteboxcrypto.com/files/2012_MISC_DRM.pdf •... • • 75 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg SUMMARY • 76 PA193 | Integrity of modules P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Summary •Dynamic libraries can be forged –make DLL preloding harder (manifest) –check input from library as untrusted •Don’t use standard C functions for temporary files –not use temporary files at all or follow security guidelines •Try to protect secrets inside binary –don’t hardcode any secrets –offload sensitive computation to secure environment (server, smart card, HSM) –use whitebox-attacker protection techniques 77 PA193 | Integrity of modules question Questions