No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Predictability of Android OpenSSL's Pseudo random number generator
Abstract
OpenSSL is the most widely used library for SSL/TLS on the Android platform. The security of OpenSSL depends greatly on the unpredictability of its Pseudo Random Number Generator (PRNG). In this paper, we reveal the vulnerability of the OpenSSL PRNG on the Android. We first analyze the architecture of the OpenSSL specific to Android, and the overall operation process of the PRNG from initialization until the session key is generated. Owing to the nature of Android, the Dalvik Virtual Machine in Zygote initializes the states of OpenSSL PRNG early upon booting, and SSL applications copy the PRNG states of Zygote when they start. Therefore, the applications that use OpenSSL generate random data from the same initial states, which is potential problem that may seriously affect the security of Android applications. Next, we investigate the possibility of recovering the initial states of the OpenSSL PRNG. To do so, we should predict the nine external entropy sources of the PRNG. However, we show that these sources can be obtained in practice if the device is fixed. For example, the complexity of the attack was O(2^{32+t}) in our smartphone, where t is the bit complexity for estimating the system boot time. In our experiments, we were able to restore the PRNG states in 74 out of 100 cases. Assuming that we knew the boot time, i.e., t=0, the average time required to restore was 35 min on a PC with four cores (eight threads). Finally, we show that it is possible to recover the PreMasterSecret of the first SSL session with O(2^{58}) computations using the restored PRNG states, if the application is implemented by utilizing org.webkit package and a key exchange scheme is RSA. It shows that the vulnerability of OpenSSL PRNG can be a real threat to the security of Android.
... however, these studies seldom analyze PRNG implementations in apps. The techniques proposed for assessing the PRNG implementations mainly focus on open-source systems (e.g., Linux [8], OpenSSL [9]). However, these techniques rely on code analysis and thus cannot be applied to analyze PRNGs of Android apps. ...
... Apart from Linux PRNG, OpenSSL is another important application for PRNG analysis [9] [41]. Kim et al. [9] investigated the Android OpenSSL PRNG. ...
... Apart from Linux PRNG, OpenSSL is another important application for PRNG analysis [9] [41]. Kim et al. [9] investigated the Android OpenSSL PRNG. Similarly, they conducted a code analysis to analyze the Android OpenSSL architecture. ...
A fundamental premise of SMS One-Time Password (OTP) is that the used pseudo-random numbers (PRNs) are uniquely unpredictable for each login session. Hence, the process of generating PRNs is the most critical step in the OTP authentication. An improper implementation of the pseudo-random number generator (PRNG) will result in predictable or even static OTP values, making them vulnerable to potential attacks. In this paper, we present a vulnerability study against PRNGs implemented for Android apps. A key challenge is that PRNGs are typically implemented on the server-side, and thus the source code is not accessible. To resolve this issue, we build an analysis tool, \sysname, to assess implementations of the PRNGs in an automated manner without the source code requirement. Through reverse engineering, \sysname identifies the apps using SMS OTP and triggers each app's login functionality to retrieve OTP values. It further assesses the randomness of the OTP values to identify vulnerable PRNGs. By analyzing 6,431 commercially used Android apps downloaded from \tool{Google Play} and \tool{Tencent Myapp}, \sysname identified 399 vulnerable apps that generate predictable OTP values. Even worse, 194 vulnerable apps use the OTP authentication alone without any additional security mechanisms, leading to insecure authentication against guessing attacks and replay attacks.
... For example, several articles [5][6][7][8] pointed out that the important parameters (e.g., PreMasterSecret) can be exposed in the embedded system, Androids, and OpenSSL from predictable random numbers generated at boot time because collecting noise sources is limited. In addition, the Bitcoin wallet was attacked in the elliptic curve digital signature algorithm (ECDSA) process because the Java-based RNG (SecureRandom class) is vulnerable [9]. ...
... In transport layer security (TLS) as well as secure shell (SSH), numerous certificates were collected and several identical keys were found by extracting common primes using the greatest common divisor (GCD) algorithm. Moreover, Kim et al. [7] showed that PreMasterSecret can be recovered by 2 52 complexity in the handshake process of OpenSSL in the Android. Their attacks can be possible because predictable random numbers are generated from insufficient entropy at boot time. ...
... In particular, because of limited noise sources in the embedded environments, this feature is closely related to LRNG security. In addition, as observed in [7,8], the predictability of random numbers generated at the initial boot time can be feasible because it is not easy to collect sufficient noise sources from booting. ...
Over the past decade, several security issues with Linux Random Number Generator (LRNG) on PCs and Androids have emerged. The main problem involves the process of entropy harvesting, particularly at boot time. An entropy source in the input pool of LRNG is not transferred into the non-blocking output pool if the entropy counter of the input pool is less than 192 bits out of 4098 bits. Because the entropy estimation of LRNG is highly conservative, the process may require more than one minute for starting the transfer. Furthermore, the design principle of the estimation algorithm is not only heuristic but also unclear. Recently, Google released an Internet of Things (IoT) operating system called Brillo based on the Linux kernel. We analyze the behavior of the random number generator in Brillo, which inherits that of LRNG. In the results, we identify two features that enable recovery of random numbers. With these features, we demonstrate that random numbers of 700 bytes at boot time can be recovered with the success probability of 90% by using time complexity for 5.20 × 2 40 trials. Therefore, the entropy of random numbers of 700 bytes is merely about 43 bits. Since the initial random numbers are supposed to be used for sensitive security parameters, such as stack canary and key derivation, our observation can be applied to practical attacks against cryptosystem.
... These use random numbers from a physical process-such as thermal noiseto harvest entropy [GLSV12]. Although they still do not qualify as mathematically random, these sequences have in some cases been extremely unpredictable-but note that from a cryptographic perspective, they have turned out to be less secure than originally anticipated [KHL13]. In any case, harvesting entropy may also lead to problems: for example, large logs may be required to satisfy the trustworthy AI requirements, which designers can review to fix a problem in the event of tragedies. ...
... But still, how current computers would generate true random sequences raises a series of philosophical questions: If hardware random generators in combination with pseudo-random generators replaced the notion of pure random oracle for lack of a better implementation in our current hardware, and machines proliferated around us making decisions about our lives, the world could become potentially distressing. In our previous AV example, perhaps owners would be particularly interested in breaking into the code of the pseudo-random number generator in their car to anticipate its decisions-even with entropy sources attacks are possible [KHL13]. Similarly, law firms could invest resources in finding the pseudo-random code behind AI judges to find the best strategies for their clients. ...
As \emph{artificial intelligence} (AI) systems are increasingly involved in decisions affecting our lives, ensuring that automated decision-making is fair and ethical has become a top priority. Intuitively, we feel that akin to human decisions, judgments of artificial agents should necessarily be grounded in some moral principles. Yet a decision-maker (whether human or artificial) can only make truly ethical (based on any ethical theory) and fair (according to any notion of fairness) decisions if full information on all the relevant factors on which the decision is based are available at the time of decision-making. This raises two problems: (1) In settings, where we rely on AI systems that are using classifiers obtained with supervised learning, some induction/generalization is present and some relevant attributes may not be present even during learning. (2) Modeling such decisions as games reveals that any -- however ethical -- pure strategy is inevitably susceptible to exploitation. Moreover, in many games, a Nash Equilibrium can only be obtained by using mixed strategies, i.e., to achieve mathematically optimal outcomes, decisions must be randomized. In this paper, we argue that in supervised learning settings, there exist random classifiers that perform at least as well as deterministic classifiers, and may hence be the optimal choice in many circumstances. We support our theoretical results with an empirical study indicating a positive societal attitude towards randomized artificial decision-makers, and discuss some policy and implementation issues related to the use of random classifiers that relate to and are relevant for current AI policy and standardization initiatives.
... Unfortunately, there are scenarios where this is not always possible. An important example is the boot-entropy starvation problem [8,9,10,11], which appears when a system (e.g., boot-loader or operating system) requires entropy at boot-time but it is unable to generate or collect enough entropy. ...
... As we have discussed and analyzed in sections III, IV and V, there are many solutions to generate and collect entropy to be consumed by the final user. Unfortunately, after analyzing all the literature, we found that none of those techniques can be employed to solve the boot-time starvation problem [8,9,10,11]. ...
Due to the impracticability of generating true randomness by running deterministic algorithms in computers, boot-loaders and operating systems undergo the lack of enough supplies of entropy at boot-time. This problem remains a challenge and affects all computer systems, including virtualization technologies. Unfortunately, this situation leads to undesired side effects, affecting the security of important kernel components and causing large blocking waits in the start-up of userland processes. For example, SSHD is delayed up to 4 minutes. In this paper, we analyze the boot-time entropy starvation problem, performing a comprehensive analysis of the Linux kernel boot process revealing that the problem not only affects userland applications but up to 33 kernel functions at boot time. Those functions are weakly fed by random numbers from a non-initialized CSPRNG. To overcome this problem, we propose E-Boot, a novel technique that provides high-quality random numbers to guest virtual machines. E-Boot is the first technique that completely satisfies the entropy demand of virtualized boot-loaders and operating systems at boot time. We have implemented E-Boot in Linux v5.3 and our experiments show that it effectively solves the boottime entropy starvation problem. Our proposal successfully feeds bootloaders and boot time Linux kernel hardening techniques with high-quality random numbers, reducing also to zero the number of userspace blocks and delays. The total time overhead introduced by E-Boot is around 2 μs and has zero memory overhead, since the memory is freed before the kernel boot ends, which makes E-boot a practical solution for cloud systems.
... OpenSSL uses a pseudo random number generator (PRNG) to output random numbers. Some literatures related to the security of the PRNG have been proposed [10][11][12][13][14][15]. The security of OpenSSL's PRNG in Android and Debian has been reported in [10,14]. ...
... The authors in [10][11][12] gave the algorithms of RAND add() and RAND bytes() as in Algorithms 1 and 2. ...
In 2007, a real faked X.509 certificate based on the chosen-prefix collision of MD5 was presented by Marc Stevens. In the method, attackers needed to predict the serial number of X.509 certificates generated by CAs besides constructing the collision pairs of MD5. After that, the randomness of the serial number is required. Then, in this case, how do we predict the random serial number? Thus, the way of generating serial number in OpenSSL was reviewed. The vulnerability was found that the value of the field “not before” of X.509 certificates generated by OpenSSL leaked the generating time of the certificates. Since the time is the seed of generating serial number in OpenSSL, we can limit the seed in a narrow range and get a series of candidate serial numbers and use these candidate serial numbers to construct faked X.509 certificates through Stevens’s method. Although MD5 algorithm has been replaced by CAs, the kind of attack will be feasible if the chosen-prefix collision of current hash functions is found in the future. Furthermore, we investigate the way of generating serial numbers of certificates in other open source libraries, such as EJBCA, CFSSL, NSS, Botan, and Fortify.
... The core feature that defines a strong key is its randomness. However, the randomness of keys is still a widely neglected issue [123] and, not surprisingly, weak entropy, and weak random number generation have been the cause of several significant vulnerabilities [63]. Even long-standing cryptographic libraries such as ...
... OpenSSL have been recurrently affected by this problem [63,94]. Importantly, recent research has shown that this problem also affects networking equipment [6,50,51]. ...
... The core feature that defines a strong key is its randomness. However, the randomness of keys is still a widely neglected issue [121] and, not surprisingly, weak entropy and weak random number generation have been the cause of several significant vulnerabilities [62]. Even long-standing cryptographic libraries such as OpenSSL have been recurrently affected by this problem [62,92]. ...
... However, the randomness of keys is still a widely neglected issue [121] and, not surprisingly, weak entropy and weak random number generation have been the cause of several significant vulnerabilities [62]. Even long-standing cryptographic libraries such as OpenSSL have been recurrently affected by this problem [62,92]. Importantly, recent research has shown that this problem also affects networking equipment [6,49,50]. ...
Software-defined networking (SDN) decouples the control and data planes of traditional networks, logically centralizing the functional properties of the network in the SDN controller. While this centralization brought advantages such as a faster pace of innovation, it also disrupted some of the natural defenses of traditional architectures against different threats. The literature on SDN has mostly been concerned with the functional side, despite some specific works concerning non-functional properties such as security or dependability. Though addressing the latter in an ad-hoc, piecemeal way may work, it will most likely lead to efficiency and effectiveness problems. We claim that the enforcement of non-functional properties as a pillar of SDN robustness calls for a sys-temic approach. We further advocate, for its materialization, the reiteration of the successful formula behind SDN: 'logical centralization'. As a general concept, we propose anchor, a subsystem architecture that promotes the logical centralization of non-functional properties. To show the effectiveness of the concept, we focus on security in this article: we identify the current security gaps in SDNs and we populate the architecture middleware with the appropriate security mechanisms in a global and consistent manner. Essential security mechanisms provided by anchor include reliable entropy and resilient pseudo-random generators, and protocols for secure registration and association of SDN devices. We claim and justify in the article that centralizing such mechanisms is key for their effectiveness by allowing us to define and enforce global policies for those properties; reduce the complexity of controllers and forwarding devices; ensure higher levels of robustness for critical services; foster interoperability of the non-functional property enforcement mechanisms; and promote the security and resilience of the architecture itself. We discuss design and implementation aspects, and we prove and evaluate our algorithms and mechanisms , including the formalisation of the main protocols and the verification of their core security properties using the Tamarin prover. We would like to thank the anonymous reviewers for the insightful comments. 1 INTRODUCTION Software-defined networking (SDN) moves the control function out of the forwarding devices, logically centralizing the functional properties of the network. This decoupling between control and data plane leads to higher flexibility and programmability of network control, enabling fast innovation. In spite of all of these benefits, this decoupling, associated with a common southbound application programming interface (API; e.g., OpenFlow), has removed an important natural protection of traditional networks. Specifically, the heterogeneity and diversity of configuration protocols, the closed (and proprietary) nature of the devices, and the distributed nature of the control plane. Hence, from a security perspective, SDN introduces new attack vectors and radically changes the threat surface [37, 70, 110]. So far, the SDN literature has been mostly concerned with functional properties, such as improved routing and traffic engineering [8, 57, 77], efficient topology discovery [94], and enhanced network security services [3, 54, 102, 111], among others, by exploiting the ability to program the control plane. Non-functional properties are those related to reaching goals of quality of the operation of the global system rather than to its specific behavior. However, SDN currently leaves the achievement of non-functional properties to individual mechanisms or services. Works having recently seen the light, concerned in principle with non-functional properties, address specific implementations of functions or services, albeit dependability related [17, 26, 59, 69, 105] or security related [99, 110, 114, 115]. To give an example, security services such as firewalls or Deep Packet Inspection (DPI) mechanisms for attack detection and mitigation rely essentially on functional properties of the network, that is, they are concerned with the SDN function of generating and remotely installing the appropriate flow rules in the data plane. As effective as the former examples may be, their impact on the desired system-level non-functional property (say, integrity or availability) ends up being bottom-up, in an ad-hoc, piecemeal way. It may work for specific cases but, generically, it is most likely to create gaps in the enforcement of the property, which would inevitably lead to efficiency and effectiveness problems (as we show in Section 3). For instance: insecure control plane associations or communications, network information disclosure, spoofing attacks, and hijacking of devices can easily compromise the network operation; performance crises can escalate to globally affect quality of service (QoS); and unavailability and lack of reliability of controllers, forwarding devices, or clock synchronization parameters can considerably degrade network operation [4, 65, 110].
... In the third step, the algorithm connects nodes to the two special nodes Exception and Granted (lines [19][20][21][22][23][24][25]. Particularly, lines 20-21 add an edge from a predicate n to Granted if n currently has only one edge in the AFG. ...
... Android permission mappings have inspired researchers to identify vulnerabilities at both the framework and application layer. Prominent examples include the re-delegation problem [12,25], content provider leaks [15], issues in push-cloud messaging [23], in the app uninstallation process [38], crypto misuse in apps [9,20] and others [3,10]. In addition, Whyper [28] and AutoCog [29] check the inconsistency between the required permissions and the description of apps. ...
The Android research community has long focused on building an Android API permission specification, which can be leveraged by app developers to determine the optimum set of permissions necessary for a correct and safe execution of their app. However, while prominent existing efforts provide a good approximation of the permission specification, they suffer from a few shortcomings. Dynamic approaches cannot generate complete results, although accurate for the particular execution. In contrast, static approaches provide better coverage, but produce imprecise mappings due to their lack of path-sensitivity. In fact, in light of Android's access control complexity, the approximations hardly abstract the actual co-relations between enforced protections. To address this, we propose to precisely derive Android protection specification in a path-sensitive fashion, using a novel graph abstraction technique. We further showcase how we can apply the generated maps to tackle security issues through logical satisfiability reasoning. Our constructed maps for 4 Android Open Source Project (AOSP) images highlight the significance of our approach, as ~41% of APIs' protections cannot be correctly modeled without our technique.
... The core feature that defines a strong key is its randomness. However, the randomness of keys is still a widely neglected issue [ Vassilev and Hall 2014], and not surprisingly, weak entropy, and weak random number generation have been the cause of several significant vulnerabilities in software and devices [Albrecht et al. 2015;Hastings et al. 2016;Heninger et al. 2012;Kim et al. 2013]. Recent research has shown that there are still non-negligible problems for hosts and networking devices [Albrecht et al. 2015;Hastings et al. 2016;Heninger et al. 2012]. ...
... For instance, a common pattern found in low-resource devices, such as switches, is that the random number generator of the operating system may lack the input of external sources of entropy to generate reliable cryptographic keys. Even long-standing cryptographic libraries such as OpenSSL have been recurrently affected by this problem [Kim et al. 2013;OpenSSL.org 2016]. ...
Software-defined networking (SDN) decouples the control and data planes of traditional networks, logically centralizing the functional properties of the network in the SDN controller. While this centralization brought advantages such as a faster pace of innovation, it also disrupted some of the natural defenses of traditional architectures against different threats. The literature on SDN has mostly been concerned with the functional side, despite some specific works concerning non-functional properties such as security or dependability. Though addressing the latter in an ad-hoc, piecemeal way may work, it will most likely lead to efficiency and effectiveness problems.
We claim that the enforcement of non-functional properties as a pillar of SDN robustness calls for a systemic approach. We further advocate, for its materialization, the reiteration of the successful formula behind SDN: ‘logical centralization’. As a general concept, we propose anchor, a subsystem architecture that promotes the logical centralization of non-functional properties. To show the effectiveness of the concept, we focus on security in this article: we identify the current security gaps in SDNs and we populate the architecture middleware with the appropriate security mechanisms in a global and consistent manner. Essential security mechanisms provided by anchor include reliable entropy and resilient pseudo-random generators, and protocols for secure registration and association of SDN devices.
We claim and justify in the article that centralizing such mechanisms is key for their effectiveness by allowing us to define and enforce global policies for those properties; reduce the complexity of controllers and forwarding devices; ensure higher levels of robustness for critical services; foster interoperability of the non-functional property enforcement mechanisms; and promote the security and resilience of the architecture itself. We discuss design and implementation aspects, and we prove and evaluate our algorithms and mechanisms, including the formalisation of the main protocols and the verification of their core security properties using the Tamarin prover.
... Second, OpenSSL is complex and highly configurable. This has been the source of many security incidents, i.e., developers and users frequently use the library in an inappropriate way [25], [26], [27]. It has also been shown that the majority of the security incidents are still caused by errors and misconfiguration of systems [28], [29]. ...
... Second, OpenSSL is complex and highly configurable. This has been the source of many security incidents, i.e., developers and users frequently use the library in an inappropriate way[25],[26],[27]. It has also been shown that the majority of the security incidents are still caused by errors and misconfiguration of systems[28],[29]. ...
Security is an increasingly fundamental requirement in Software-Defined Networking (SDN). We estimate the slow pace of adoption of secure mechanisms to be a consequence of the overhead of traditional solutions and of the complexity of the support infrastructure required. In this paper we address these two problems as a first step towards defining a secure SDN architecture. First, we investigate the impact of essential security primitives on control plane performance. Our analysis sheds light on the importance of a judicious choice of security primitives (and of their implementations) to obtain security at reasonable cost. Based on these findings, we propose a lightweight security architecture specifically tailored to SDN. While offering the same security properties of standard TLS and PKI implementations, our solution is less complex, prone to be more robust, with a code footprint one order of magnitude smaller, and finally, outperforming reference alternatives such as OpenSSL, by around 30%.
... In transformation iii, we match for code Ljava/crypto/spec/ IvParameterSpec to locate indicator instruction (line 5). Then, we replace code that is the root cause of the misuse (line 1) with code that generates the randomized value (line [6][7][8][9][10][11][12][13][14][15][16][17][18][19][20]. The randomized value is stored in the field iv-Params (line 8). ...
... There are many research e↵orts focusing on di↵erent types of vulnerabilities, such as component hijacking vulnerability [27][28] [34], cryptographic misuses [11][29] [23], and SSL misuses [12][10] [19]. Component hijacking vulnerability is related to the threats among the components in Android architecture that implement the access control improperly on external requests and leak the privacy accidentally. ...
Cryptography is increasingly being used in mobile applications to provide various security services; from user authentication, data privacy, to secure communications. However, there are plenty of mistakes that developers could accidentally make when using cryptography in their mobile apps and such mistakes can lead to a false sense of security. Recent research efforts indeed show that a significant portion of mobile apps in both Android and iOS platforms misused cryptographic APIs. In this paper, we present CDRep, a tool for automatically repairing cryptographic misuse defects in Android apps. We classify such defects into seven types and manually assemble the corresponding fix patterns based on the best practices in cryptographic implementations. CDRep consists of two phases, a detection phase which identifies defect locations in a mobile app and a repair phase which repairs the vulnerable app automatically. In our validation, CDRep is able to successfully repair 94.5% of 1,262 vulnerable apps. Furthermore, CDRep is lightweight, the average runtime to generate a patch is merely 19.3 seconds and the size of a repaired app increases by only 0.667% on average.
... Pekerjaan lain termasuk mengevaluasi risiko keamanan yang dihasilkan dari cacat desain dalam perpesanan push-cloud (Han et al., (2014)), mengidentifikasi risiko proses uninstall aplikasi Android (Qiu et al., (2016)) dan risiko komponen Clipboard Android dan mekanisme berbagi (Smith et al., (2013)). Dua studi terbaru meneliti lebih lanjut penyalahgunaan crypto di aplikasi Android (Fratantonio et al., (2013);Lee et al., (2013)). Pekerjaan lainnya termasuk menemukan kerentanan pada desain Android yang cacat, seperti penelitian yang dilakukan oleh Huang et al., (2015) mengeksploitasi kelemahan di server sistem Android untuk memasang beberapa serangan DoS dan penelitian Qian et al., (2015) mengungkap penyedia root Android dan menunjukkan bahwa eksploitasi yang direkayasa dengan baik ini tidak baik. ...
Android adalah sistem yang kompleks, yang komponen dan aplikasinya dimaksudkan untuk bekerja bersama, menimbulkan hubungan saling ketergantungan yang sangat rumit di antara. Sementara itu, ekosistem Android dikenal sangat beragam dan terdesentralisasi: setiap versi OS dikustomisasi dan dikustomisasi ulang oleh berbagai pihak hampir secara independen dan digunakan oleh siapa saja yang dapat membuat aplikasi untuk versi tersebut. Android melindungi aset informasinya melalui kotak pasir aplikasi dan model izin, di mana setiap aplikasi berjalan dalam kompartemennya sendiri dan hanya dapat mengakses sumber daya global yang sensitif dan komponen aplikasi lainnya (penyedia konten, layanan, aktivitas, penerima broadcast) dengan izin yang tepat. Penelitian ini menggunakan pengurkuran Harehunter dengan tujuan untuk mendeteksi kerentanan Hare dalam aplikasi sistem Android secara otomatis. Eveluasi kinerja Harehunter dan HareGuard dilakukan dalam penelitian ini, yang keduanya terbukti sangat efektif. Pendekatan yang diguanakan disini adalah analisis diferensial, dengan mencari semua kode yang diekstrak, didekompilasi, dan file manifes untuk definisi atribut yang ditargetkan sebagai langkap awal, dan menjalankan parser XML. Hasil penelitian ini menunjukkan bahwa dampak Hares sangat signifikan. Penerapan HareGuard dalam penelitian ini terbukti efektif dalam mendeteksi semua aplikasi serangan yang dibuat. Evaluasi lebih lanjut terhadap kinerja berdampak pada inang sistem minimum. Untuk penelitian dimasa depan, agar Harehunter lebih efektif, disarankan untuk menggunakan pengaalisa yang lebih mumpuni. Sehingga arah ini dapat dieksplorasi lebih dalam lagi.
... Other study includes evaluating security risks resulting from design flaws in push-cloud messaging (Han et al., (2014)), identifying risks of Android app uninstall processes (Qiu et al., (2016)) and risks of Android Clipboard components and mechanisms sharing (Smith et al., (2013)). "2 new studies have more investigated code abuse in Android applications" (Fratantonio et al., (2013); Lee et al., (2013)). Other work includes finding vulnerabilities in flawed Android designs, such as research conducted by Huang et al., (2015) exploiting weaknesses in Android system servers to mount multiple DoS attacks and Qian et al., (2015) research uncovering Android root providers and shows that this well-engineered exploit is no good protected, and can be extremely dangerous if exploited. ...
Android is a complicated system that applications and component are usable and support for multiple work together, giving rise to highly complex interdependence relationships. Meanwhile, the Android environment is notable for being greatlty disparate and decentralized: different Operation System version is personalized and re-personalized by different parties about fast and used by whoever that can develop an application for that version. Android secure its explanation sources over an app sandbox and permissions model, where each application execution in this part can entrance only suspectible overall assets and another application component (value providers, services, activities, publication receivers) by the appropriate liscense. This study uses Harehunter measurement to automatically detect Hare vulnerabilities in Android system applications. Harehunter and HareGuard performance evaluations were carried out in this study, both of which proved to be highly effective. The approach used here is divergent investigation, by searching all quoted, decompiled script, and obvious data for targeted attribute determination as an initial step, and running an XML parser. The outcome of this research show that the impact of Hares is very significant. The application of HareGuard in this study proved to be effective in detecting all attack applications that were made. Further evaluation of the performance impact on the minimum system host. For future research, to make Harehunter more effective, it is suggested to use a more qualified analyzer. So that this direction can be explored in more depth.
... Typically, on the Android platform, OpenSSL is used to generate random numbers. The work [9] showed the weakness of the OpenSSL library in generating random numbers on the Android platform. ...
The paper proposes an algorithm for generating random numbers based on sensors of a gyroscope, magnetometer, accelerometer on mobile devices, and discusses the sensors of a gyroscope, magnetometer and accelerometer. The random bit generator uses smartphone sensors as entropy source. It collects raw data from smartphone sensors and processes they by given algorithm. The degree of randomness of random bits generated using the proposed algorithm was tested using statistical tests NIST SP 800-22, and a test result was given. It is important to ensure the safe storage, transmission and use of data in these information systems. To solve these problems, cryptographic methods are used more often than other methods of data protection. Cryptographic algorithms are the basis of cryptographic data protection methods. Most cryptographic algorithms are publicly available and the key plays the role of a secret value when applied. The generations of these secret keys and sometime private keys are based on random number generations.
... Android vulnerability detection. There are also many works on vulnerability identification of Android operation systems, including the leakage of content provider [31], data encryption vulnerabilities [32], [33], cloud push-messaging services vulnerabilities [34] and others [35], [36], [37], [38]. Specially, AutoCog [39] analyzed and checked that if the app's required permission conforms to the description of the permission. ...
The Android system manages access to sensitive APIs by permission enforcement. An application (app) must declare proper permissions before invoking specific Android APIs. However, there is no official documentation providing the complete list of permission-protected APIs and the corresponding permissions to date. Researchers have spent significant efforts extracting such API protection mapping from the Android API framework, which leverages static code analysis to determine if specific permissions are required before accessing an API. Nevertheless, none of them has attempted to analyze the protection mapping in the native library (i.e., code written in C and C++), an essential component of the Android framework that handles communication with the lower-level hardware, such as cameras and sensors. While the protection mapping can be utilized to detect various security vulnerabilities in Android apps, such as permission over-privilege and component hijacking, imprecise mapping will lead to false results in detecting such security vulnerabilities. To fill this gap, we develop a prototype system, named NatiDroid, to facilitate the cross-language static analysis to benchmark against two state-of-the-art tools, termed Axplorer and Arcade. We evaluate NatiDroid on more than 11,000 Android apps, including system apps from custom Android ROMs and third-party apps from the Google Play. Our NatiDroid can identify up to 464 new API-permission mappings, in contrast to the worst-case results derived from both Axplorer and Arcade, where approximately 71% apps have at least one false positive in permission over-privilege and up to 3.6% apps have at least one false negative in component hijacking. Additionally, we identify that 24 components with at least one Native-triggered component hijacking vulnerability are misidentified by two benchmarks.
... Kaplan et al. (2014) demonstrated an IPv6 denial of service attack and a stack canary bypass with the weaknesses of insufficient entropy in boot-time of Android. Kim, Han & Lee (2013) presented a technique to recover PreMasterSecret (PMS) of the first SSL session in Android by 2 58 complexity since PMS is generated from insufficient entropy of OpenSSL PRNG at boot-time. Ristenpart & Yilek (2010), Bernstein et al. (2013), Michaelis, Meyer & Schwenk (2013), Schneier et al. (2015), and Yoo, Kang & Yeom (2017) describe the attacks caused by weakness of entropy collectors or incorrect estimations of the entropy that are exaggerated or too conservative. ...
In cryptosystems and cryptographic modules, insufficient entropy of the noise sources that serve as the input into random number generator (RNG) may cause serious damage, such as compromising private keys. Therefore, it is necessary to estimate the entropy of the noise source as precisely as possible. The National Institute of Standards and Technology (NIST) published a standard document known as Special Publication (SP) 800-90B, which describes the method for estimating the entropy of the noise source that is the input into an RNG. The NIST offers two programs for running the entropy estimation process of SP 800-90B, which are written in Python and C++. The running time for estimating the entropy is more than one hour for each noise source. An RNG tends to use several noise sources in each operating system supported, and the noise sources are affected by the environment. Therefore, the NIST program should be run several times to analyze the security of RNG. The NIST estimation runtimes are a burden for developers as well as evaluators working for the Cryptographic Module Validation Program. In this study, we propose a GPU-based parallel implementation of the most time-consuming part of the entropy estimation, namely the independent and identically distributed (IID) assumption testing process. To achieve maximal GPU performance, we propose a scalable method that adjusts the optimal size of the global memory allocations depending on GPU capability and balances the workload between streaming multiprocessors. Our GPU-based implementation excluded one statistical test, which is not suitable for GPU implementation. We propose a hybrid CPU/GPU implementation that consists of our GPU-based program and the excluded statistical test that runs using OpenMP. The experimental results demonstrate that our method is about 3 to 25 times faster than that of the NIST package.
... As technology adoption advances, incidents become more frequent. In 2013, a component of Android responsible for generating secure random numbers contained a weakness that rendered all Android wallets generated until then vulnerable to theft [8], [9], [10]. In 2015, a flaw in FreeBSD's kernel made SSH keys and keys generated by OpenSSL vulnerable due to the possible predictability of a random number generator [11]. ...
p class="Abstract">Statistical sampling and simulations produced by algorithms require fast random number generators; however, true random number generators are often too slow for the purpose, so pseudorandom number generators are usually more suitable. But choosing and using a pseudorandom number generator is no simple task; most pseudorandom number generators fail statistical tests. Default pseudorandom number generators offered by programming languages usually do not offer sufficient statistical properties. Testing random number generators so as to choose one for a project is essential to know its limitations and decide whether the choice fits the project’s objectives. However, this study presents a reproducible experiment that demonstrates that, despite all the contributions it made when it was first published, the popular NIST SP 800-22 statistical test suite as implemented in the software package is inadequate for testing generators.</p
... Several versions of Android were shipped with a broken default pseudorandom generator that has not been correctly seeded on start up. This allowed an attacker to recover its state, see Kim, Han, and Lee [16], and lead to Android Bitcoin wallets which generated predictable private keys. In a future version of our wallet, this should be taken into account. ...
We show how to realize two-factor authentication for a Bitcoin wallet. To do so, we explain how to employ an ECDSA adaption of the two-party signature protocol by MacKenzie and Reiter (Int J Inf Secur 2(3–4):218–239, 2004. doi:10.1007/s10207-004-0041-0) in the context of Bitcoin and present a prototypic implementation of a Bitcoin wallet that offers both: two-factor authentication and verification over a separate channel. Since we use a smart phone as the second authentication factor, our solution can be used with hardware already available to most users and the user experience is quite similar to the existing online banking authentication methods.
... Analysis of cryptographic APIs used by applications [5], [6], pseudorandom number generators [7], and imperfect SSL/TLS implementation [8], [9], [10], [11], [12], [13], [14] focused on cryptographic use inside applications. ...
Android applications are digitally signed using developers' signing keys. Since each key is associated with a developer, it can be used to establish trust between applications published by the author, i.e., apps signed with the same key are allowed to update themselves if package names are identical, or access each other's resources. However, if a signature is generated using a weak algorithm such as MD5, then apps signed with the corresponding key are exposed to several risks, such as hijacking apps with fake updates or granting permissions to a malicious app. In this work, we analyze several Android apps to identify the threats caused by using weak algorithms. Our study uncovered the following findings: Of the more than one million apps collected from Google Play, 223 and 52, 866 were digitally signed using the weak algorithms of 512-bit RSA key and MD5, respectively. We identified the causal mechanisms for generating certificates that employ weak algorithms, and found that these mechanisms can be attributed to app-building frameworks and online app-building services. On the basis of these findings, we provide guidelines for stakeholders of the Android app distribution ecosystem.
... The anticipation of Android OpenSSL's pseudo random number generator [5] helps in sorting out PID of the processes. Nearly everyone in the Internet is using Open SSL for SSL/TLS on the Android platform for information security which in-turn depends significantly on the irregularity of its Pseudo Random Number Generator (PRNG). ...
The True Random Number Generator (TRNG) is an important module for countless cryptographically secure appliances. TRNG generation technique requires custom made hardware with quantum phenomena, which on the whole are expensive research components. A secure and sound TRNG design is anticipated at this time, which is based on the permutation of sensor feeds and combination of noise patterns from the peripherals of any Android smartphone. The source for this generator is the selected features from the in-built hardware components namely accelerometer, gyroscope, magnetometer, WiFi signal measure, cell tower information, GPS coordinates and battery thermal noise. Additionally, Process ID (PID) of the corresponding Android processes is given as key vector to augment the entropy and also addresses some of the security concern like confidentiality, integrity and availability of the authentic sources. Hardware-Based Random Number Generator (HRNG) can be achieved by combing the source of the user, their corresponding parameters and the measure of imperfection.
... It has inspired other researchers to identify vulnerabilities at apps and framework. Prominent examples include the re-delegation problem [15], content provider leaks [20], issues in push-cloud messaging [27], in the app uninstallation process [36], crypto misuse in apps [12], [24] and others [13]. In addition, Whyper [30] and AutoCog [31] check the inconsistency between an app's permissions and its description. ...
... H I indicates the round intervals at which a 16-bit hash of cipher-state must be computed. And I C ∈ [8,32] indicates the number of bits used to generate a random number (pepper) which is chosen between [0, 2 I C ). The pepper value is used as number of iterations performed to initialize the cipher. ...
This paper introduces Freestyle, a randomized and variable round version of the ChaCha cipher. Freestyle uses the concept of hash based halting condition where a decryption attempt with an incorrect key is likely to take longer time to halt. This makes Freestyle resistant to key-guessing attacks i.e. brute-force and dictionary based attacks. Freestyle demonstrates a novel approach for ciphertext randomization by using random number of rounds for each block, where the exact number of rounds are unknown to the receiver in advance. Freestyle provides the possibility of generating $2^{128}$ different ciphertexts for a given key, nonce, and message; thus resisting key and nonce reuse attacks. Due to its inherent random behavior, Freestyle makes cryptanalysis through known-plaintext, chosen-plaintext, and chosen-ciphertext attacks difficult in practice. On the other hand, Freestyle has costlier cipher initialization process, typically generates 3.125% larger ciphertext, and was found to be 1.6 to 3.2 times slower than ChaCha20. Freestyle is suitable for applications that favor ciphertext randomization and resistance to key-guessing and key reuse attacks over performance and ciphertext size. Freestyle is ideal for applications where ciphertext can be assumed to be in full control of an adversary, and an offline key-guessing attack can be carried out.
... This attack is due to a serious bug in the process of generating randomness for the nonces k. Another devastating flaw was revealed in August 2013, when one realized that the Java class SecureRandom could generate collisions in the nonce values used for ECDSA in implementations of Bitcoin on Android [KHL13] (if a user signs two different messages using the same ephemeral key, then the long-term ECDSA private key is immediately computable from the public key and the signatures). ...
This book constitutes the thoroughly refereed post-conference proceedings of the 10th International Conference on Security for Information Technology and Communications, SecITC 2017, held in Bucharest, Romania, in June 2017.
The 6 revised full papers presented together with 7 invited talks were carefully reviewed and selected from 22 submissions. The papers present advances in the theory, design, implementation, analysis, verification, or evaluation of secure systems and algorithms.
... Previous studies[24],[36]also use unguarded public interfaces in vulnerable Android apps to launch attacks. Two recent studies further examine the crypto misuse in Android apps[26],[38]. These vulnerabilities are partially due to developers' mis-configurations of app components or misinterpretation of Android's security protection. ...
... Heninger et al. [22] performed a pairwise GCD on RSA moduli obtained from scanning the IPv4 address space, finding many shared factors and weak keys; the root cause was the lack of entropy available shortly after boot in many network devices. Kim et al. [31] showed that a related problem affected OpenSSL on Android. ...
In December 2015, Juniper Networks announced multiple security vulnerabilities stemming from unauthorized code in ScreenOS, the operating system for their NetScreen VPN routers. The more sophisticated of these vulnerabilities was a passive VPN decryption capability, enabled by a change to one of the elliptic curve points used by the Dual EC pseudorandom number generator. In this paper, we describe the results of a full independent analysis of the ScreenOS randomness and VPN key establishment protocol subsystems, which we carried out in response to this incident. While Dual EC is known to be insecure against an attacker who can choose the elliptic curve parameters, Juniper had claimed in 2013 that ScreenOS included countermeasures against this type of attack. We find that, contrary to Juniper's public statements, the ScreenOS VPN implementation has been vulnerable since 2008 to passive exploitation by an attacker who selects the Dual EC curve point. This vulnerability arises due to apparent flaws in Juniper's countermeasures as well as a cluster of changes that were all introduced concurrently with the inclusion of Dual EC in a single 2008 release. We demonstrate the vulnerability on a real NetScreen device by modifying the firmware to install our own parameters, and we show that it is possible to passively decrypt an individual VPN session in isolation without observing any other network traffic. We investigate the possibility of passively fingerprinting ScreenOS implementations in the wild. This incident is an important example of how guidelines for random number generation, engineering, and validation can fail in practice.
... Argyros and Kiayias in [AK12] presented some practical techniques and algorithms for exploiting randomness vulnerabilities in PHP. More recently, a flaw in the Android PRNG, identified by Kim et al. [KHL13], has been actively exploited against Android-based Bitcoin wallets. ...
Cryptography has been a key factor in enabling services and products trading over the Internet.Cloud computing has expanded this revolution and it has become a highly demanded service or utility due to the advantages of highcomputing power, cheap cost of services, high performance, scalability, accessibility as well as availability. Along with the rise of newbusinesses, protocols for secure computation have as well emerged. The goal of this thesis is to contribute in the direction of securing existing Internet protocols by providing an analysis of the sources of randomness of these protocols and to introduce better protocols for cloud computingenvironments. We propose new constructions, improving the efficiency of current solutions in order to make them more accessible andpractical. We provide a detailed security analysis for each scheme under reasonable assumptions. We study the security in a cloud computing environment in different levels. On one hand, we formalize a framework to study some popular real-life pseudorandom number generators used in almost every cryptographic application. On the other, we propose two efficient applications for cloud computing. The first allows a user topublicly share its high-entropy secret across different servers and to later recover it by interacting with some of these servers using only his password without requiring any authenticated data. The second, allows a client to securely outsource to a server an encrypted database that can be searched and modified later.
... Poor initialization can also weaken the random numbers in operating systems like Windows 2000 (Dorrendorf et al., 2009 ). A few more examples of vulnerabilities due to initialization problems or other bad quality random number generators are weak RSA key generation in network devices (Heninger et al., 2012; Lenstra et al., 2012 ), repeated or guessable keys produced inside smart cards (Bernstein et al., 2013; Courtois et al., 2013; Nohl et al., 2008 ) and the predictable random sequences that are used for cryptographic purposes in Android (Kim et al., 2013; Michaelis et al., 2013). In this respect, physical RNGs, including QRNGs, can serve as way to seed CSPRNGs, preferably as an additional source of entropy. ...
Random numbers are a fundamental resource in science and engineering with important applications in simulation and cryptography. The inherent randomness at the core of quantum mechanics makes quantum systems a perfect source of entropy. Quantum random number generation is one of the most mature quantum technologies with many alternative generation methods. We discuss the different technologies in quantum random number generation from the early devices based on radioactive decay to the multiple ways to use the quantum states of light to gather entropy from a quantum origin. We also discuss randomness extraction and amplification and the notable possibility of generating trusted random numbers even with untrusted hardware using device independent generation protocols.
Random numbers are very important for the security of computer system. However, generating qualified random numbers is difficult because we cannot always successfully introduce dedicated random number hardware into computer system. Although most operating systems provide random number generation capabilities, the effective entropy supply is still dependent on the hardware platform including memory and clocks etc. However, obtaining hardware events such as clocks requires system privileges, which is not conducive for entropy estimation at the application layer. In contrast, data related to the sensor hardware can be extracted directly at the application layer. These sensor data contain some randomness and may be used as a noise source. In this way, applications can use these sensors to implement their own proprietary random number generators. Before taking these sensors as the noise source, it is necessary to fully evaluate their entropy supply capability. In this paper, 300 Android smartphones and 30 iOS smartphones are selected as samples and their sensor entropy supply capabilities are comprehensively evaluated. Based on the entropy evaluation results, we give some suggestions on how to generate random numbers using these sensor data. We first design a framework for evaluating the entropy supply capability for smartphone sensors, based on the min-entropy estimation method proposed in NIST SP 800-90B. According to this framework, we simulate stationary and mobile working states for each smartphone, and collect sufficient sensor data as the min-entropy estimation dataset. The min-entropy estimation results show that in the stationary working state, each ACCELEROMETER sensor data collection can obtain at least 1.5 bits of entropy in Android, while each GYROSCOPE sensor data collection can obtain at least 20 bits of entropy in iOS. In the mobile working state, each ACCELEROMETER sensor data collection can obtain at least 1.9 bits of entropy, while each GYROSCOPE sensor data acquisition in iOS system can obtain at least 27 bits of entropy. This means that we can still get a stable entropy output from the sensor even when the smartphone is in stationary working state. Statistical analysis of the data using cross correlation methods suggests it is hard for an attacker to guess or predict the random numbers generated by a smartphone through another smartphone put in the similar external environment.
This paper introduces Freestyle, a randomized, and variable round version of the ChaCha cipher. Freestyle demonstrates the concept of hash based halting condition, where a decryption attempt with an incorrect key is likely to take longer time to halt. This makes it resistant to key-guessing attacks i.e. brute-force and dictionary based attacks. Freestyle uses a novel approach for ciphertext randomization by using random number of rounds for each block of message, where the exact number of rounds are unknown to the receiver in advance. Due to its inherent random behavior, Freestyle provides the possibility of generating up to 2²⁵⁶ different ciphertexts for a given key, nonce, and message; thus resisting key and nonce reuse attacks. This also makes cryptanalysis through known-plaintext, chosen-plaintext, and chosen-ciphertext attacks difficult in practice. Freestyle is highly customizable, making it suitable for both low-powered devices and security-critical applications. It is ideal for: (i) applications that favor ciphertext randomization and resistance to key-guessing and key reuse attacks; and (ii) situations where ciphertext is in full control of an adversary for carrying out an offline key-guessing attack.
TrustZone is a hardware security technique in ARM mobile devices. Using TrustZone, software components running within the secure world can be completely isolated from the normal world. In order to support multiple trusted applications, TrustZone runs its own operating system, called the secure OS, within the secure world. Unfortunately, as all trusted applications are running on the same secure OS instance, compromising the secure OS leads to compromising all trusted applications. This paper presents PrOS, our mechanism to privatize secure OSes through direct virtualization of TrustZone. PrOS allows each trusted application to run with its own secure OS such that the secure OS is no longer a single point of security failure. One particular challenge for PrOS lies in how efficiently to implement software-only virtualization for TrustZone for a practical deployment in real systems despite the condition that the current ARM architectures do not support hardware-assisted virtualization for TrustZone. Fortunately, we have found several common design features inherent in the secure OS to leverage for optimally tailoring the TrustZone virtualization scheme. According to our evaluation, PrOS incurs 0.02% and 1.18% performance overheads on average in the normal and secure worlds, respectively, demonstrating its effectiveness in field.
Constant blinding is considered an effective mitigation against JIT spray attacks. In this paper, we study the design and implementation of constant blinding mechanism in Flash Player and analyse the weakness in its pseudo random number generator (PRNG). We demonstrate how such weakness can be exploited to recover the seed value in PRNG, thus bypass the constant blinding in Flash Player.
A pseudo-random number generator is a deterministic algorithm that produces numbers whose distribution is indistinguishable from uniform. A formal security model for pseudo-random number generator with input was proposed in 2005 by Barak and Halevi. This model involves an internal state that is refreshed with a (potentially biased) external random source, and a cryptographic function that outputs random numbers from the internal state. We briefly discuss the Barak-Halevi model and its extension proposed in 2013 by Dodis, Pointcheval, Ruhault, Wichs and Vergnaud to include a new security property capturing how a pseudo-random number generator should accumulate the entropy of the input data into the internal state. This property states that a pseudo-random number generator with input should be able to eventually recover from compromise even if the entropy is injected into the system at a very slow pace, and expresses the real-life expected behavior of existing designs. We also outline some variants of this model that were proposed recently.
Android system versions update and iterate frequently with severe fragmentation. The distribution of the various Android versions’ market share is scattered, making system-level vulnerabilities’ risk extensive and serious. For the limitations of the present research, we design and implement a new comprehensive system-level vulnerability detection system VScanner. For the first time VScanner is based on Lua script engine as the core. It gives priority to dynamic detection by exploiting, and static detection by feature matching is complementary. Vulnerability trigger is developed by the form of plugins, and it bases on vulnerability taxonomy by POCAS, which shows good scalability. For system-level vulnerabilities, we have implemented 18 plugins, which all are system-level vulnerabilities in high risk. By experimental evaluation, VScanner has high efficiency, low false alarm rate, and good effects on vulnerability detection.
We propose a mathematical model of the entropy estimator in the Linux random number generator. First, we construct a probability model for random event times in entropy sources, and then precisely derive probability distributions for the first, second, and third time differences. Second, we obtain the probability distribution for the minimum of absolute values of these differences, which is used for the estimated entropy in the Linux system. Moreover, we provide several simulations that display the accuracy of our results for various parameters.
The importance of random number generators (RNGs) to various computing applications is well understood. To ensure a quality level of output, high-entropy sources should be utilized as input. However, the algorithms used have not yet fully evolved to utilize newer technology. Even the Android pseudo RNG (APRNG) merely builds atop the Linux RNG to produce random numbers. This paper presents an exploratory study into methods of generating random numbers on sensor-equipped mobile and Internet of Things devices. We first perform a data collection study across 37 Android devices to determine two things-how much random data is consumed by modern devices, and which sensors are capable of producing sufficiently random data. We use the results of our analysis to create an experimental framework called SensoRNG, which serves as a prototype to test the efficacy of a sensor-based RNG. SensoRNG employs collection of data from on-board sensors and combines them via a lightweight mixing algorithm to produce random numbers. We evaluate SensoRNG with the National Institute of Standards and Technology statistical testing suite and demonstrate that a sensor-based RNG can provide high quality random numbers with only little additional overhead.
In this work we demonstrate various weaknesses of the random number generator (RNG) in the OpenSSL cryptographic library. We show how OpenSSL’s RNG, knowingly in a low entropy state, potentially leaks low entropy secrets in its output, which were never intentionally fed to the RNG by client code, thus posing vulnerabilities even when in the given usage scenario the low entropy state is respected by the client application. Turning to the core cryptographic functionality of the RNG, we show how OpenSSL’s functionality for adding entropy to the RNG state fails to be effectively a mixing function. If an initial low entropy state of the RNG was falsely presumed to have 256 bits of entropy based on wrong entropy estimations, this causes attempts to recover from this state to succeed only in long term but to fail in short term. As a result, the entropy level of generated cryptographic keys can be limited to 80 bits, even though thousands of bits of entropy might have been fed to the RNG state previously. In the same scenario, we demonstrate an attack recovering the RNG state from later output with an off-line effort between \(2^{82}\) and \(2^{84}\) hash evaluations, for seeds with an entropy level n above 160 bits. We also show that seed data with an entropy of 160 bits, fed into the RNG, under certain circumstances, might be recovered from its output with an effort of \(2^{82}\) hash evaluations. These results are highly relevant for embedded systems that fail to provide sufficient entropy through their operating system RNG at boot time and rely on subsequent reseeding of the OpenSSL RNG. Furthermore, we identify a design flaw that limits the entropy of the RNG’s output to 240 bits in the general case even for an initially correctly seeded RNG, despite the fact that a security level of 256 bits is intended.
We show how to realize two-factor authentication for a Bitcoin wallet. To do so, we explain how to employ an ECDSA adaption of the two-party signature protocol by MacKenzie and Reiter (2004) in the context of Bitcoin and present a prototypic implementation of a Bitcoin wallet that offers both: two-factor authentication and verification over a separate channel. Since we use a smart phone as the second authentication factor, our solution can be used with hardware already available to most users and the user experience is quite similar to the existing online banking authentication methods.
Virtualized environments are widely thought to cause problems for software-based random number generators (RNGs), due to use of virtual machine (VM) snapshots as well as fewer and believed-to-be lower quality entropy sources. Despite this, we are unaware of any published analysis of the security of critical RNGs when running in VMs. We fill this gap, using measurements of Linux's RNG systems (without the aid of hardware RNGs, the most common use case today) on Xen, VMware, and Amazon EC2. Despite CPU cycle counters providing a significant source of entropy, various deficiencies in the design of the Linux RNG makes its first output vulnerable during VM boots and, more critically, makes it suffer from catastrophic reset vulnerabilities. We show cases in which the RNG will output the exact same sequence of bits each time it is resumed from the same snapshot. This can compromise, for example, cryptographic secrets generated after resumption. We explore legacy-compatible countermeasures, as well as a clean-slate solution. The latter is a new RNG called Whirlwind that provides a simpler, more-secure solution for providing system randomness.
The built-in Pseudo Random Number Generator (PRNG) of OpenSSL on Android platform is important for producing the encryption keys and nonce needed for SSL/TLS communication. In addition, it is also widely used in generating random numbers for many applications irrelevant to SSL. We demonstrated that the initial OpenSSL PRNG state of Android apps can be restored practically, and claimed that a PreMasterSecret (PMS) can be recovered in certain apps using the RSA key agreement scheme at CCS2013. In this paper, we investigate more deeply the practical effect of the predictability of OpenSSL PRNG. First, we precisely analyze, and reduce the complexity of a PMS recovery attack on SSL with the RSA key exchange by analyzing the ASLR mechanism of Android. As a result, we show that the PMS can be recovered in O(246) computations with a probability of 25%. Next, we show that the attack is also applicable to the PMS of the ECDH key exchange by analyzing the heap memory pattern. We confirmed experimentally that the PMS can be recovered in real-time with a probability of 20%. Finally, we show the relation between the predictability of OpenSSL PRNG and the vulnerability of Android SecureRandom java class.
Elastic mobile cloud computing (EMCC) enables the seamless and transparent use of cloud resource to augment the capability of mobile devices by off-loading parts of mobile devices' tasks to cloud according to the real-time user requirement. By summarizing the service providing models of EMCC, we divide existing EMCC models into two categories: computing migration-mobile cloud computing(CM-MCC), in which the mobile devices employ the cloud to perform the parts of their computing intensive tasks; and cloud agent-mobile cloud computing(CA-MCC), in which the cloud maintains one or more virtual mobile devices for each mobile device and these virtual mobile devices are synchronized with the mobile device to complete various tasks such as computing, storage, security and communication instead of the mobile device. Then the applicable scenarios, the implementation method, the key issues, and the future research of EMCC models in each category are studied. After that, we analyze the critical security threats of EMCC, including users' error operations or malicious actions, malicious applications, communications security problems, and cloud computing security issues such as the vulnerabilities of virtual system, multi-tenant problems, malicious cloud service providers. The corresponding defenses of these threats are discussed. At last, we point out that security is a key issue for EMCC.
Many Android apps have a legitimate need to communicate over the Internet and are then responsible for protecting potentially sensitive data during transit. This paper seeks to better understand the potential security threats posed by benign Android apps that use the SSL/TLS protocols to protect data they transmit. Since the lack of visual security indicators for SSL/TLS usage and the inadequate use of SSL/TLS can be exploited to launch Man-in-the-Middle (MITM) attacks, an analysis of 13,500 popular free apps downloaded from Google's Play Market is presented.
We introduce MalloDroid, a tool to detect potential vulnerability against MITM attacks. Our analysis revealed that 1,074 (8.0%) of the apps examined contain SSL/TLS code that is potentially vulnerable to MITM attacks. Various forms of SSL/TLS misuse were discovered during a further manual audit of 100 selected apps that allowed us to successfully launch MITM attacks against 41 apps and gather a large variety of sensitive data. Furthermore, an online survey was conducted to evaluate users' perceptions of certificate warnings and HTTPS visual security indicators in Android's browser, showing that half of the 754 participating users were not able to correctly judge whether their browser session was protected by SSL/TLS or not. We conclude by considering the implications of these findings and discuss several countermeasures with which these problems could be alleviated.
In this paper we present a practically feasible attack on RSA-based sessions in SSL/TLS protocols. These protocols incorporate the PKCS#1 (v. 1.5) encoding method for the RSA encryption of a premaster- secret value. The premaster-secret is the only secret value that is used for deriving all the particular session keys. Therefore, an attacker who can recover the premaster-secret can decrypt the whole captured SSL/TLS session. We show that incorporating a version number check over PKCS#1 plaintext used in the SSL/TLS creates a side channel that allows the attacker to invert the RSA encryption. The attacker can then either recover the premaster-secret or sign a message on behalf of the server. Practical tests showed that two thirds of randomly chosen Internet SSL/TLS servers were vulnerable. The attack is an extension of Bleichenbacher's attack on PKCS#1 (v. 1.5). We introduce the concept of a bad-version oracle (BVO) that covers the side channel leakage, and present several methods that speed up the original algorithm. Our attack was successfully tested in practice and the results of complexity measurements are presented in the paper. Plugging a testing server (2x Pentium III/1.4 GHz, 1 GB RAM, 100 Mb/s Ethernet, OS RedHat 7.2, Apache 1.3.27), it was possible to achieve a speed of 67.7 BVO calls per second for a 1024 bits RSA key. The median time for a whole attack on the premaster-secret could be then estimated as 54 hours and 42 minutes. We also propose and discuss countermeasures, which are both cryptographically acceptable and practically feasible.
Simple password authentication is often used e.g. from an email software application to a remote IMAP server. This is frequently done in a protected peer-to-peer tunnel, e.g. by SSL/TLS.
At Eurocrypt’02, Vaudenay presented vulnerabilities in padding schemes used for block ciphers in CBC mode. He used a side channel, namely error information in the padding verification. This attack was not possible against SSL/TLS due to both unavailability of the side channel (errors are encrypted) and premature abortion of the session in case of errors. In this paper we extend the attack and optimize it. We show it is actually applicable against latest and most popular implementations of SSL/TLS (at the time this paper was written) for password interception.
We demonstrate that a password for an IMAP account can be intercepted when the attacker is not too far from the server in less than an hour in a typical setting.
We conclude that these versions of the SSL/TLS implementations are not secure when used with block ciphers in CBC mode and propose ways to strengthen them. We also propose to update the standard protocol.
One of the services provided by the operating system to the applications is random number generation. For security reasons, the Linux Random Number Generator is built upon the combination of a deterministic algorithm known as the cryptographic post-processing and an unpredictable physical phenomenon called an Entropy Source. While the various cryptographic post-processing algorithms and their properties are well described in the literature, the entropy collection process itself is little studied. This report first presents the different approaches to random number generation, and then details the architecture of the Linux Random Number Generator. Then, we present the experiments we performed to monitor entropy transfers. Our results show that the main source of randomness in the system is the behavior of the hard drive, and that most random numbers produced by the generator are actually consumed by the kernel itself.
This paper introduces a fast blockwise chosen-plaintext attack against SSL 3.0 and TLS 1.0. We also de-scribe one application of the attack that allows an attacker to efficiently decrypt and obtain authentication tokens embedded in HTTPS requests 1 The resulting exploits work for major web browsers at the time of writing.
RSA and DSA can fail catastrophically when used with malfunctioning random number generators, but the extent to which these problems arise in practice has never been comprehensively studied at Internet scale. We perform the largest ever network survey of TLS and SSH servers and present evidence that vulnerable keys are surprisingly widespread. We find that 0.75% of TLS certificates share keys due to insufficient entropy during key generation, and we suspect that another 1.70% come from the same faulty implementations and may be susceptible to compromise. Even more alarmingly, we are able to obtain RSA private keys for 0.50% of TLS hosts and 0.03% of SSH hosts, because their public keys shared nontrivial common factors due to entropy problems, and DSA private keys for 1.03% of SSH hosts, because of insufficient signature randomness. We cluster and investigate the vulnerable hosts, finding that the vast majority appear to be headless or embedded devices. In experiments with three software components commonly used by these devices, we are able to reproduce the vulnerabilities and identify specific software behaviors that induce them, including a boot-time entropy hole in the Linux random number generator. Finally, we suggest defenses and draw lessons for developers, users, and the security community.
SSL (Secure Sockets Layer) is the de facto standard for secure Internet communications. Security of SSL connections against an active network attacker depends on correctly validating public-key certificates presented when the connection is established.
We demonstrate that SSL certificate validation is completely broken in many security-critical applications and libraries. Vulnerable software includes Amazon's EC2 Java library and all cloud clients based on it; Amazon's and PayPal's merchant SDKs responsible for transmitting payment details from e-commerce sites to payment gateways; integrated shopping carts such as osCommerce, ZenCart, Ubercart, and PrestaShop; AdMob code used by mobile websites; Chase mobile banking and several other Android apps and libraries; Java Web-services middleware including Apache Axis, Axis 2, Codehaus XFire, and Pusher library for Android and all applications employing this middleware. Any SSL connection from any of these programs is insecure against a man-in-the-middle attack.
The root causes of these vulnerabilities are badly designed APIs of SSL implementations (such as JSSE, OpenSSL, and GnuTLS) and data-transport libraries (such as cURL) which present developers with a confusing array of settings and options. We analyze perils and pitfalls of SSL certificate validation in software based on these APIs and present our recommendations.
Timing attacks are usually used to attack weak computing devices such as smartcards. We show that timing attacks apply to general software systems. Specifically, we devise a timing attack against OpenSSL. Our experiments show that we can extract private keys from an OpenSSL-based web server running on a machine in the local network. Our results demonstrate that timing attacks against network servers are practical and therefore security systems should defend against them. (c) 2005 Elsevier B.V. All rights reserved.
Random number generators (RNGs) are consistently a weak link in the secure use of cryptography. Routine cryp- tographic operations such as encryption and signing can fail spectacularly given predictable or repeated random- ness, even when using good long-lived key material. This has proved problematic in prior settings when RNG imple- mentation bugs, poor design, or low-entropy sources have resulted in predictable randomness. We investigate a new way in which RNGs fail due to reuse of virtual machine (VM) snapshots. We exhibit such VM reset vulnerabilities in widely-used TLS clients and servers: the attacker takes advantage of (or forces) snapshot replay to compromise sessions or even expose a server's DSA signing key. Our next contribution is a backwards-compatible framework for hedging routine cryptographic operations against bad ran- domness, thereby mitigating the damage due to randomness failures. We apply our framework to the OpenSSL library and experimentally confirm that it has little overhead.
We report on the aftermath of the discovery of a severe vul- nerability in the Debian Linux version of OpenSSL. Systems aected by the bug generated predictable random numbers, most importantly public/private keypairs. To study user response to this vulnerability, we collected a novel dataset of daily remote scans of over 50,000 SSL/TLS-enabled Web servers, of which 751 displayed vulnerable certicates. We report three primary results. First, as expected from pre- vious work, we nd an extremely slow rate of xing, with 30% of the hosts vulnerable when we began our survey on day 4 after disclosure still vulnerable almost six months later. However, unlike conventional vulnerabilities, which typically show a short, fast xing phase, we observe a much atter curve with
Address-Space Layout Randomization (ASLR) techniques prevent intruders from locating target functions by randomizing the process layout. Prior ASLR techniques defended against single-target brute force attacks, which work by locating a single, omnipotent system library function such as execve(). These techniques are not sufficient to defend against chained return-into-lib(c) attacks that call a sequence of system library functions. In this paper, we describe the Island Code Transformation (ICT) that addresses chained return-into-lib(c) attacks. A code island is a block of code that is isolated in the address space from other code blocks. Island code not only randomizes the base pointers used in memory mapping, but also maximizes the entropy in function layout (that is, knowing the location and extent of one function gains the attacker little knowledge as to the memory location of other functions). We also provide an efficacy analysis of randomization schemes based on combinations of available ASLR techniques. Our analysis shows that ICT is exponentially more effective than any prior ASLR technique in defending against brute-force searches for addresses of multiple target functions - a key component of chained return-into-lib(c) attacks. ICT uses a predefined rerandomization threshold, that determines how frequently (in terms of failed attacks) the process layout is re-randomized to balance security and availability. Our overhead measurement on some well-known GNU applications shows that it takes less than 0.05 second to load/rerandomize a process with the necessary C system library functions in code islands, and our technique introduces a 3-10% run-time overhead caused by inter-island control transfers. We, therefore, conclude that ICT is well-suited for dedicated servers.
Analysis of a Strong Pseudo Random Number Generator by anatomizing Linux' Random Number Device
- T Biege
Openssl-Predictable Random Number Generator,DSA-1571--1. Available from http
- Debian The
- Project
The Linux Pseudorandom Number Generator Revisited.IACR ePrint Arcive 2012/251 Available from http
- P Lacharme
Lessons Learned from Previous SSL/TLS Attacks: A Brief Chronology of Attacks and Weakness. IACR ePrint Arcive 2013/049 Available from http
- C Meyer
- J Schwenk