A look into the information your smartphone leaks

The file attached to this record is the author's final peer reviewed version. The Publisher's final version can be found by following the DOI link.Some smartphone applications (apps) pose a risk to users’ personal information. Events of apps leaking information stored in smartphones illustrate the danger that they present. In this paper, we investigate the amount of personal information leaked during the installation and use of apps when accessing the Internet. We have opted for the implementation of a Man-in-the-Middle proxy to intercept the network traffic generated by 20 popular free apps installed on different smartphones of distinctive vendors. This work describes the technical considerations and requirements for the deployment of the monitoring WiFi network employed during the conducted experiments. The presented results show that numerous mobile and personal unique identifiers, along with personal information are leaked by several of the evaluated apps, commonly during the installation process

Unified Description for Network Information Hiding Methods

Until now hiding methods in network steganography have been described in arbitrary ways, making them difficult to compare. For instance, some publications describe classical channel characteristics, such as robustness and bandwidth, while others describe the embedding of hidden information. We introduce the first unified description of hiding methods in network steganography. Our description method is based on a comprehensive analysis of the existing publications in the domain. When our description method is applied by the research community, future publications will be easier to categorize, compare and extend. Our method can also serve as a basis to evaluate the novelty of hiding methods proposed in the future.Comment: 24 pages, 7 figures, 1 table; currently under revie

Localization to Enhance Security and Services in Wi-Fi Networks under Privacy Constraints

Developments of seamless mobile services are faced with two broad challenges, systems security and user privacy - access to wireless systems is highly insecure due to the lack of physical boundaries and, secondly, location based services (LBS) could be used to extract highly sensitive user information. In this paper, we describe our work on developing systems which exploit location information to enhance security and services under privacy constraints. We describe two complimentary methods which we have developed to track node location information within production University Campus Networks comprising of large numbers of users. The location data is used to enhance security and services. Specifically, we describe a method for creating geographic firewalls which allows us to restrict and enhance services to individual users within a specific containment area regardless of physical association. We also report our work on LBS development to provide visualization of spatio-temporal node distribution under privacy considerations

Saving Brian's Privacy: the Perils of Privacy Exposure through Reverse DNS

Given the importance of privacy, many Internet protocols are nowadays designed with privacy in mind (e.g., using TLS for confidentiality). Foreseeing all privacy issues at the time of protocol design is, however, challenging and may become near impossible when interaction out of protocol bounds occurs. One demonstrably not well understood interaction occurs when DHCP exchanges are accompanied by automated changes to the global DNS (e.g., to dynamically add hostnames for allocated IP addresses). As we will substantiate, this is a privacy risk: one may be able to infer device presence and network dynamics from virtually anywhere on the Internet -- and even identify and track individuals -- even if other mechanisms to limit tracking by outsiders (e.g., blocking pings) are in place. We present a first of its kind study into this risk. We identify networks that expose client identifiers in reverse DNS records and study the relation between the presence of clients and said records. Our results show a strong link: in 9 out of 10 cases, records linger for at most an hour, for a selection of academic, enterprise and ISP networks alike. We also demonstrate how client patterns and network dynamics can be learned, by tracking devices owned by persons named Brian over time, revealing shifts in work patterns caused by COVID-19 related work-from-home measures, and by determining a good time to stage a heist

Regional Address Registries, Governance and Internet Freedom

Regional Internet Address Registries (RIRs) are private, nonprofit and transnational governance entities that evolved organically with the growth of the Internet to manage and coordinate Internet Protocol addresses. The RIR's management of Internet address resources is becoming more contentious and more central to global debates over Internet governance. This is happening because of two transformational problems: 1) the depletion of the IPv4 address space; and 2) the attempt to introduce more security into the Internet routing system. We call these problems "transformational" because they raise the stakes of the RIR's policy decisions, make RIR processes more formal and institutionalized, and have the potential to create new, more centralized control mechanisms over Internet service providers and users. A danger in this transition is that the higher stakes and centralized control mechanisms become magnets for political contention, just as ICANN's control of the DNS root did. In order to avoid a repeat of the problems of ICANN, we need to think carefully about the relationship between RIRs, governments, and Internet freedom. In particular, we need to shield RIRs from interference by national governments, and strengthen and institutionalize their status as neutral technical coordinators with limited influence over other areas of Internet governance

{SoK}: {An} Analysis of Protocol Design: Avoiding Traps for Implementation and Deployment

Today's Internet utilizes a multitude of different protocols. While some of these protocols were first implemented and used and later documented, other were first specified and then implemented. Regardless of how protocols came to be, their definitions can contain traps that lead to insecure implementations or deployments. A classical example is insufficiently strict authentication requirements in a protocol specification. The resulting Misconfigurations, i.e., not enabling strong authentication, are common root causes for Internet security incidents. Indeed, Internet protocols have been commonly designed without security in mind which leads to a multitude of misconfiguration traps. While this is slowly changing, to strict security considerations can have a similarly bad effect. Due to complex implementations and insufficient documentation, security features may remain unused, leaving deployments vulnerable. In this paper we provide a systematization of the security traps found in common Internet protocols. By separating protocols in four classes we identify major factors that lead to common security traps. These insights together with observations about end-user centric usability and security by default are then used to derive recommendations for improving existing and designing new protocols---without such security sensitive traps for operators, implementors and users

{SoK}: {An} Analysis of Protocol Design: Avoiding Traps for Implementation and Deployment

Today's Internet utilizes a multitude of different protocols. While some of these protocols were first implemented and used and later documented, other were first specified and then implemented. Regardless of how protocols came to be, their definitions can contain traps that lead to insecure implementations or deployments. A classical example is insufficiently strict authentication requirements in a protocol specification. The resulting Misconfigurations, i.e., not enabling strong authentication, are common root causes for Internet security incidents. Indeed, Internet protocols have been commonly designed without security in mind which leads to a multitude of misconfiguration traps. While this is slowly changing, to strict security considerations can have a similarly bad effect. Due to complex implementations and insufficient documentation, security features may remain unused, leaving deployments vulnerable. In this paper we provide a systematization of the security traps found in common Internet protocols. By separating protocols in four classes we identify major factors that lead to common security traps. These insights together with observations about end-user centric usability and security by default are then used to derive recommendations for improving existing and designing new protocols---without such security sensitive traps for operators, implementors and users

Fault Tolerant Scalable Support for Network Portability and Traffic Engineering

The P-SHIM6 architecture provides ISP independence to IPv6 sites without compromising scalability. This architecture is based on a middle-box, the P-SHIM6, which manages the SHIM6 protocol exchange on behalf of the nodes of a site, which are configured with provider independent addresses. Incoming and outgoing packets are processed by the P-SHIM6 box, which can assign different locators to a given communication, either when it is started, or dynamically after the communication has been established. As a consequence, changes required for provider portability are minimized, and fine-grained Traffic Engineering can be enforced at the P-SHIM6 box, in addition to the fault tolerance support provided by SHIM6.This project has been supported by the RiNG project IST-2005-035167 and by the IMPROVISA project TSI2005-07384-C03-02.Publicad