Universities have adopted remote proctoring software to maintain academic integrity during invigilated online exams. The use of this software, however, has raised privacy, security, and ethical concerns, including surveillance of students' bedrooms, processing of student data, and racially biased monitoring. Additionally, this software can require substantial local computer permissions. Prior work has explored student and educator perceptions and use of this software, but there remains a gap in understanding how senior administrators decide to adopt (or not adopt) these tools at an institutional level. This paper presents the results of interviews with 20 university administrators from the U.S. and Australia towards understanding how and why their universities decided to centrally adopt (or not adopt) remote proctoring software. We find that academic governance processes included senior administrators, legal, and IT teams, even during the rush at the start of the COVID-19 pandemic, but that students were sometimes structurally excluded from the process of adoption. We explore how administrators weighed the need for academic integrity against competing concerns about privacy, security, ethics, and long-term operational issues like cost. We find that universities adopted remote proctoring despite concerns about privacy and security, sometimes attempting to mitigate these concerns. As academia continues to explore hybrid learning, our research can guide institutions in the adoption of Educational Technologies and the assessment of student learning.

APIs often transmit far more data to client applications than they need, and in the context of web applications, often do so over public channels. This issue, termed Excessive Data Exposure (EDE), was OWASP's third most significant API vulnerability of 2019. However, there are few automated tools---either in research or industry---to effectively find and remediate such issues. This is unsurprising as the problem lacks an explicit test oracle: the vulnerability does not manifest through explicit abnormal behaviours (e.g., program crashes or memory access violations).

ccheck, a lenient automatic grader and C style-checker, to guide students to improve their coding practices. Many computing classes rely heavily on autograders--software that automates grading and alleviates staff workload in classes with large enrollments. At best, autograders offer timely and consistent feedback to students. However, existing autograders primarily judge on functional correctness---they are generally strict and inflexible in marking beginner programming assignments. They tend not to provide feedback on programming style and structure, which instead requires delayed, tedious manual assessment. ccheck, the tool we introduce, aims to address this gap and provide more meaningful, real-time feedback with a pedagogical focus.

Modern secure messaging protocols typically aim to provide deniability. Achieving this requires that convincing cryptographic transcripts can be forged without the involvement of genuine users. In this work, we observe that parties may wish to revoke deniability and avow a conversation after it has taken place. We propose a new protocol called Not-on-the-Record-Yet (NOTRY) which enables users to prove a prior conversation transcript is genuine. As a key building block we propose avowable designated verifier proofs which may be of independent interest. Our implementation in- curs roughly 8× communication and computation overhead over the standard Signal protocol during regular operation. We find it is nonetheless deployable in a realistic setting as key exchanges (the source of the overhead) still complete in just over 1ms on a modern computer. The avowal protocol induces only constant computation and communication performance for the communicating parties and scales linearly in the number of messages avowed for the verifier—in the tens of milliseconds per avowal.

Modern cryptography requires the ability to securely generate pseudorandom numbers. However, despite decades of work on side-channel attacks, there is little discussion of their application to pseudorandom number generators (PRGs). In this work we set out to address this gap, empirically evaluating the side-channel resistance of common PRG implementations.We find that hard-learned lessons about side-channel leakage from encryption primitives have not been applied to PRGs, at all abstraction levels. At the design level, the NIST-recommended CTR_DRBG does not have forward security if an attacker is able to compromise the state (e.g., via a side-channel). At the primitive level, popular implementations of CTR_DRBG such as OpenSSL's FIPS module and NetBSD's kernel use leaky T-table AES as their underlying cipher, enabling cache side-channel attacks. Finally, we find that many implementations make parameter choices that enable an attacker to fully exploit side-channels and recover secret keys from TLS connections.We empirically demonstrate our attack in two scenarios. First, we carry out a cache attack that recovers the private state from vulnerable CTR_DRBG implementations when the TLS client connects to an attacker-controlled server. We then subsequently use the recovered state to compute the client's long-term authentication keys, thereby allowing the attacker to impersonate the client. In the second scenario, we show that an attacker can exploit the high temporal resolution provided by Intel SGX to carry out a blind attack to recover CTR_DRBG's state within three AES encryptions, without viewing output, and thus decrypt passively collected TLS connections from the victim.

The ANSI X9.17/X9.31 pseudorandom number generator design was first standardized in 1985, with variants incorporated into numerous cryptographic standards over the next three decades. The design uses timestamps together with a statically keyed block cipher to produce pseudo-random output. It has been known since 1998 that the key must remain secret in order for the output to be secure. However, neither the FIPS 140-2 standardization process nor NIST's later descriptions of the algorithm specified any process for key generation. We performed a systematic study of publicly available FIPS 140- 2 certifications for hundreds of products that implemented the ANSI X9.31 random number generator, and found twelve whose certification documents use of static, hard-coded keys in source code, leaving the implementation vulnerable to an attacker who can learn this key from the source code or binary. In order to demonstrate the practicality of such an attack, we develop a full passive decryption attack against FortiGate VPN gateway products using FortiOS v4 that recovers the private key in seconds. We measure the prevalence of this vulnerability on the visible Internet using active scans, and demonstrate state recovery and full private key recovery in the wild. Our work highlights the extent to which the validation and certification process has failed to provide even modest security guarantees.

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.