Identifying and Testing for Insecure Paths in Authentication protocols : A Model-based Approach Jayaram KR Graduate Student - Computer Science Purdue University jayaram@purdue.edu Aditya P Mathur Professor of Computer Science Purdue University apm@purdue.edu SERC Showcase – Fall 2006 Ball State University, Muncie IN November 15-16, 2006

Research Objective To evaluate the effectiveness of statechart-based test generation techniques in Identifying insecure paths in cryptographic protocol implementations Identify stress points in the protocol which may lead to security vulnerabilities 1/12/2019

Importance Increased use of cryptographic protocols in critical systems and their increased complexity. Software errors are becoming common in protocol implementations leading to serious security flaws. [http://web.mit.edu/Kerberos/advisories/] Verification only ensures correctness of design. Need to understand the effectiveness of model-based testing approaches in security testing. 1/12/2019

Our Approach - Modeling Formalism – Statecharts [A component of UML.] Concurrency – protocols involve multiple concurrent principals. Each principal may have multiple concurrent threads of computation Need to model arbitrary computations at varying levels of abstraction – encryption, certificate validation, etc. Memory – this is critical. The use of variables is unavoidable. Principals remember keys, nonces (a value used only once), etc. Extended FSMs supporting all the above are no different from statecharts! 1/12/2019

Example – TLS Client Handshake [RFC 2246] 1/12/2019

Test Generation [1] Enhanced Wp method [Chow78] Wp method results in state-space explosion in concurrent states (due to product construction) We reduce the number of tests generated by eliminating infeasible paths Consider an example ……. 1/12/2019

Example: Concurrent State CLIENT SERVER Example: Concurrent State Request_cert(s) Request_cert(s) C1 Servcert = getcert() S1 Recv(s,cert)[Isvalid(cert)] send(client,servcert) Pubkey = getkey(cert) C2 clirandom = rand() Mess = encrypt(pubkey,clirandom) S2 recv(client,M) [M==encrypt(pubkey,clirandom)] send(serv,mess) C3 recv(serv,M) [M==encrypt(pubkey, servrandom)] S3 Servrandom = rand() Sesskey = f(clirandom,servrandom) Msg = encrypt(privkey,servrandom) A sample client -server. Client requests server’s certificate, checks whether the received certificate is valid, generates random number and sends it to server. Both client and server compute session key as a function of (clirandom, serverrandom) Sesskey = f(clirandom, servrandom) C4 send(serv,Msg) 1/12/2019

C1;S1 C2;S1 C1;S2 C2;S2 C3;S2 C2;S2 C2;S3 C4;S2 C3;S3 C3;S2 C3;S3 C3;F RED = INFEASIBLE C4;S3 C4,F 1/12/2019

Test Generation [2] Since authentication involves a significant amount of communication, there usually are many infeasible paths that can be eliminated. Use the statechart as a tool to identify malicious inputs and stress points Instantiate test traces using Boundary Value Analysis (with malicious inputs as well) Prune away those traces where variables are not under the control of tester – Try to cover those paths through BVA 1/12/2019

Test Generation [3] For TLS: Client: 13 states (handshake) * 4 states (Transmit) Server: 15 states (Handshake) * 4 states (Transmit) Total: 3120 states in product automaton, at least 1600 paths Most infeasible (because of communication)! After elimination: 32 states, 41 paths, 58 test cases Client Handshake Part 13 states, Transmit Part 4 states; Server Handshake Part 15 states, Transmit Part 4 states. So totally 13*4*15*4 = 3120 states. Most states are infeasible because the way we model, we model all local computation (on client/server) inside a state and all communication as transitions. After elimination 13 + 15 + 4 = 32 states. # of paths is greater than # of states because of error conditions (all of which lead to the final state but inturn create many paths). Test case is obtained by instantiating paths with BVA. 1/12/2019

Test Application [Example] GnuTLS Certificate Authority xinu3.cs.purdue.edu GnuTLS client xinu5.cs.purdue.edu GnuTLS server xinu10.cs.purdue.edu xinu5 & xinu10 share a common file system enabling us to easily collect coverage data Code is instrumented to collect coverage metrics using Bullseye during compilation In this case, client and server obtain certificates from a common certificate authority (CA) 1/12/2019

Sample Condition/Decision coverage We use the GNU Implementation of TLS v 1.4.1(www.gnutls.org) Three sample components Gnutls_handshake - 64% Gnutls_transmit - 73% Gnutls_algorithms - 73% Examples of uncovered code: Error checks for dynamic memory allocation Ptr = malloc(sizeof(cert)); If(ptr == NULL) { gnutls_assert(); Return GNUTLS_MEMORY_ERROR; } AN ERROR IN HANDLING NULL POINTERS MAY LEAD TO DENIAL OF SERVICE - SO TEST ENHANCEMENT BASED ON COVERAGE APPEARS ESSENTIAL 1/12/2019

Examples…contd An error here may lead to compromised sessions being stored on the server and later resumed Ret = _gnutls_handshake_hash_add_recvd(); If(ret <0){ Gnutls_assert(); _gnutls_handshake_header_buffer_clear(session); Return ret; } Tests do not cover low level decisions not explicitly modeled in the statechart Examples are contracts between functions. Function A may call Function B which is expected to return a value or -1(SYSERR). Function A may check for the return of SYSERR. But since this check isn’t modeled in the statechart, it is not guaranteed to be covered Such conditions will be covered if the SYSERR corresponds to an error condition modeled in the statechart. 1/12/2019

Research Plan – Short term Adequacy Assessment Measure adequacy of tests generated using existing metrics based on control flow and data flow Analyze whether uncovered code can lead to security vulnerabilities Adequacy Assessment using Mutation Use existing mutation techniques to assess adequacy Research on techniques to generate “security” mutants. At a high level, security mutants are mutants which nullify specific security requirements or introduce program vulnerabilities like buffer overflows, etc. 1/12/2019

Related Work Kirill Bogdanov, Automated Testing of Harel’s Statecharts, PhD thesis, University of Sheffield, Jan 2000 Simon Burton, Automatic Generation of High Integrity Test Suites from Graphical Specifications, PhD thesis, University of York, March 2002 Jayaram K R and Aditya P. Mathur, Software Engineering for Secure Software – State of the Art: A survey; SERC Tech Report SERC-TR-279; Oct 1, 2005 1/12/2019

Related Work Márcio Eduardo Delamaro, José Carlos Maldonado, Alberto Pasquini, Aditya P. Mathur: Interface Mutation Test Adequacy Criterion: An Empirical Evaluation. Empirical Software Engineering 6(2): 111-142 (2001) Aditya P. Mathur, W. Eric Wong: An Empirical Comparison of Data Flow and Mutation-Based Test Adequacy Criteria. Softw. Test., Verif. Reliab. 4(1): 9-31 (1994) 1/12/2019