2009-srg/dispatcher-botnet-reverse-engineering-dawn-song.key 2009-srg/images/buffer-deconstruction.png 2009-srg/images/dependency-chain.png 2009-srg/images/encoding.png 2009-srg/images/field-attributes.png 2009-srg/images/message-field-tree.png 2009-srg/images/open-protocol-analysis.png cs7001/assignments/03-mini/Makefile cs7001/assignments/03-mini/evaluation.tex cs7001/assignments/03-mini/intro.tex cs7001/assignments/03-mini/paper.bib cs7001/assignments/03-mini/paper.tex cs7001/assignments/03-mini/relatedwork.tex cs7001/assignments/03-mini/rest.tex @@ -20,19 +20,18 @@ \section{Problem} % (fold) \label{sec:Problem} -As cellular devices become more ubiquitous, we must be aware of the severe vulnerabilities on both cellular devices and networks. -Improving the resilience and security of such devices should be considered a top priority. -As the desktop world has shown us, infection is inevitable. -We propose a system that allows for recovery of compromised devices using a new network resource. Network providers will be able to -recover from attacks on devices, while providing uninterrupted functionality to its users. +Cellular devices are becoming increasingly ubiquitous and we must be aware of the severe vulnerabilities on them and networks they are in. +It is therefore important to improve resilience and security of these devices. However, as the desktop world has shown us, no protection is +perfect and infection is inevitable. We therefore propose a system that allows for recovery of compromised devices using a new network resource. +Network providers will be able to use our system to recover from attacks on devices, while providing virtually uninterrupted functionality to its users. % section Problem (end) \section{Architecture} % (fold) \label{sec:Architecture} -Our proposed solution consists of two main components: the device and the network. -The device section shows our decisions on hardware and software solutions to enable -remote repair functionality. The network component handles the two-way authentication of -services on the device and the establishment of a secure channel. +Our proposed solution consists of two main components: the device and the network component. +The device section outlines our decisions on hardware and software that allows us to enable +remote repair functionality. The network component provides and details of the establishment +of a secure channel and gives an overview of the system message structure. \subsection{Device} % (fold) \label{sub:Device} @@ -63,7 +62,7 @@ restoration. \subsection{Network} % (fold) \label{sub:Network} While a more secure device decreases the likelihood of infection, we can achieve -greater security by modifying the cellular network as well. +greater security by using additional cellular network resources. \paragraph{Network Infrastructure} % (fold) \label{par:Network Infrastructure} @@ -75,48 +74,53 @@ the REC to closely interact with the MSC and integrate with the rest of the netw After the authentication step a secure connection is established with the device. Messages sent over this secure channel are intercepted and handled by the secure OS on the mobile device and are not visible the application layer. These messages -allow the REC to remotely monitor and issue restore commands to the device. It is thus possible to detect misbehaving -devices and restore them to a known good state remotely with minor impact to the user. +allow the REC to remotely monitor and issue restore commands to the device. It is thus possible to detect misbehaving +devices and restore them to a known good state remotely. % paragraph Network Infrastructure (end) \paragraph{Network Authentication} -It is critical that communication between the device and REC is secured and both endpoints are authenticated as a rouge REC -could re-image devices maliciously and gain access to sensitive data. The same requirements for privacy and confidentiality -exisit in traditional 3G networks. We therefore modelled our authentication protocol after the 3G authentication protocol. -This also allows us to leverage existing 3G infrastructure and simplifies the integration into existing networks. - -3G authentication uses 4-tuples (\textit{$K_c$, RAND, XRES, AUTN}) that are provided as authentication vectors to the MSC -by the HLR. \textit{$K_c$, XRES, AUTN} are based off a pre-shared key \textit{$K_i$} between the mobile device and HLR that is not shared with the -rest of the network. The MSC receives these tuples and sends on instance of [\textit{RAND, AUTN}] to the device. The device -uses \textit{AUTN} to authenticate the network and generates \textit{XRES} as the authentication response to be verified by -the MSC. It also uses \textit{RAND} to generate a session key \textit{$K_c$} with the device. This key is then used to -symmetrically encrypt communication between the device and network. - -Authentication with the REC uses the same protocol and is based on the same 4-tuple authentication vectors generated from the pre-shared -key \textit{$K_c$}. The REC requests these tuples from the HLR similar to the MSC. We therefore require no change to the -HLR. However, the MSC needs to be aware of the REC to have the ability to hand off authorization after the 3G -authentication has been completed and receive authentication results from the REC. The MSC can use a database to -determine if authentication is required and exclude legacy devices from REC management. The full authentication flow for -both 3G and REC is outlined in Figure~\ref{fig:auth-flow}. - -A successful authentication establishes a session key \textit{$K_c$} between the device's secure OS and the REC. As a -session with the REC typically encompasses the full uptime of a device, a new session key needs to be renegotiated -periodically. Such key renegotiation is initiated by the REC and has the same flow as part 2 in Figure~\ref{fig:auth-flow}. We propose to -renegotiate the session key after every non-diagnostic request, as well as periodically\footnote{e.g., every 12 hours}. -This provides a balance between security and performance as requests for AVs on the HLR are kept low. We will be evaluating -the impact caused by the additional AVs in our performance evaluation. +It is critical that communication between the device and REC is secured and both endpoints are authenticated. An attacker +should not be able to impersonate the REC or device. The same requirements for authentication and confidentiality +exist in traditional 3G networks. We therefore modeled our authentication protocol after the existing 3G authentication protocol. +This allows us to leverage existing infrastructure and simplifies the integration into current networks. + +We do not change the basic 3G authentication, but we extend it with additional REC authentication. 3G authentication still proceeds +as expected: Authentication vectors (\textit{AV}) that consist of 4-tuples (\textit{$K_c$, RAND, XRES, AUTN}) are generated by the MSC based on a +pre-shared secret key \textit{$K_i$}. The AV is passed on to the HLR. When the HLR performs authentication with a device it extracts one tuple for use +and sends [\textit{RAND, AUTN}] to the device. It expects the device to respond correctly to \textit{RAND} through a matching \textit{XRES} and will then +use the provided session key \textit{$K_c$} for symmetric communication with the device. The device is able to authenticate the network through \textit{AUTN} +and can generate the expected response from \textit{RAND} through knowledge of the secret key. It furthermore can create the session key based on this +information. It is essential that this is achieved without ever exposing the secret key \textit{$K_i$}. + +In a traditional 3G network the device is then able to communicate securely with the network and use its resources. In our system additional +authentication with the REC is required before all network resources are available. Providers can decide to make basic voice functionality available +even without full REC authentication. + +Authentication with the REC mirrors 3G authentication and uses the same pre-shared key \textit{$K_c$}. The REC requests an AV from the +MSC and uses it in the same way than the MSC does for 3G authentication. The only difference are the endpoints of the authentication: +instead of device/MSC this step authenticates the device OS to the REC. We can archive this additional authentication without changes to HLR. +It only needs to be able to provide AVs to the REC. However, the MSC needs to be fully aware of the REC. It is required to hand off authentication +and respond to REC messages about the device and keep device status. The REC is designed to report suspicious behavior and interact with the device, +but decisions about device status are handled at the MSC. + +Figure~\ref{fig:auth-flow} shows the complete authentication flow. + +A session key is only used for one session in 3G, the same could apply to our system. However, 3G sessions are typically short while REC session +can encompass the full uptime of a device. We propose to renegotiate keys for every non-diagnostic message as well as +periodically\footnote{e.g., every 12 hours}. This provides a balance between security and performance as requests for AVs on the HLR are kept low. +We will be evaluating the impact caused by the additional AVs in our performance evaluation. Key renegotiation can only be initiated by the REC and +has the same flow as part 2 in Figure~\ref{fig:auth-flow}. \paragraph{Network Messages} -The messages between the device and the REC must be extensible and well defined as we cannot yet foresee the full feature -set of a REC in the future. We therefore define an extensible message format that is functionality-neutral. -Table~\ref{tab:msg-format} provides the detailed information of these messages. The message format includes a -unique ID, similar to a TCP sequence number, that allows the system to identify the duplicates of a request. The message -type is defined in a single byte and the message payload is specified in a Type/Length/Value tuple. TLV can be different -for different message types and responses. For example, our experimental system dump message request contains a -payload TLV of an integer level value. However, a system dump response from the device contains a data payload. - -Message flow between the device and REC can be round-trip or multi-message. Typically most of our sample requests consist -of round-trip messages to limit network traffic. A sample list of messages is available in Table~\ref{tab:network-messages}. +The message format between the device and the REC must be extensible and well defined as we cannot yet foresee the full feature +set of a REC in the future. We therefore define an extensible format that is functionality-neutral as seen in +Table~\ref{tab:msg-format}. The message format includes a unique ID, similar to a TCP sequence number, that allows the system to identify +duplicates of a request. The message type is defined in a single byte and the message payload is specified in a Type/Length/Value tuple. +TLV can be different for different message types and responses. For example, our experimental system dump message request contains only a +payload TLV of an integer value - the dump level. The corresponding system dump response contains a full TLV dump data payload. + +This ready indicates that message flow between the device and REC can be a simple round-trip or multi-message. Typically most of our sample +requests consist of round-trip messages to limit network traffic. A sample list of messages is available in Table~\ref{tab:network-messages}. \begin{table*} \centering cs6262/assignments/project/experimental-proposal/Assignment3.tex 363cd696cb784a74d3147f383cc9243aa830d61f Yacin Nadji yacin@gatech.edu http://github.com/ynadji/fall2009-homework/commit/be325f0f4bcf75669524be134392cedadbc58695 be325f0f4bcf75669524be134392cedadbc58695 2009-10-29T11:40:09-07:00 2009-10-29T11:40:09-07:00 finished 7001 progress report. updated 6262 experimental proposal. added presentation for srg 2009. f90ef49c6763498c4f7e76ce9b8828502fe56342 Yacin Nadji yacin@gatech.edu