DOCSLIB.ORG

Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Main Points • Applying last week’s lectures in practice • Creating Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D. Joseph – VPN: Virtual Private Network September 26, 2005 September 26, 2005 CS161 Fall 2005 2 Joseph/Tygar/Vazirani/Wagner What is a Secure Channel? Plaintext Plaintext Creating Secure Channels Encryption / Internet Encryption / • Authentication and Data Integrity Decryption Decryption Ciphertext and MAC – Use Public Key Infrastructure or third-party server to authenticate each end to the other • A stream with these security requirements: – Add Message Authentication Code for – Authentication integrity • Ensures sender and receiver are who they claim to be – Confidentiality • Confidentiality • Ensures that data is read only by authorized users – Data integrity – Exchange session key for encrypt/decrypt ops • Ensures that data is not changed from source to destination • Bulk data transfer – Non-repudiation (not discussed today) • Ensures that sender can’t deny message and rcvr can’t deny msg • Key Distribution and Segmentation September 26, 2005 CS161 Fall 2005 3 September 26, 2005 CS161 Fall 2005 4 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner Symmetric Key-based Symmetric Key-based Secure Channel Secure Channel Alice Bob • Sender (A) and receiver (B) share secret keys KABencrypt KABencrypt – One key for A è B confidentiality KABauth KABauth – One for A è B authentication/integrity Message MAC Compare? Message – Each message sent from A è B contains: MAC • Ciphertext = E_KABencrypt(nonce + msg) • Authenticity/Integrity check = MAC_KABauth(Ciphertext) Nonce + Message Encryption Decryption Nonce Check? C = E_KABencrypt(M), • Different keys for each direction = 4 keys MAC_KABauth(C) – KABencrypt, KABauth, KBAencrypt, KBAauth How to exchange secret keys? September 26, 2005 CS161 Fall 2005 5 September 26, 2005 CS161 Fall 2005 6 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner 1 Secure Channel: Choice #1 PKI Components • Use public key certificates • Requires Public Key Infrastructure (PKI) – Manages wide-scale public key distribution – Provides a trust distribution mechanism • PKI Properties – Authentication è via Public Key Certificates – Confidentiality è via Encryption – Integrity è via Digital Signatures September 26, 2005 CS161 Fall 2005 7 September 26, 2005 CS161 Fall 2005 8 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner Certification Authority Digital Certificate • People, processes responsible for creation, • Signed data structure that binds delivery and management of digital certificates an entity with its corresponding • Organized in a hierarchy public key – Enables delegation of authority (sign on behalf of X) Root CA (Verisign) – Signed by a recognized and trusted authority = Certification Authority CA-1 (yahoo.com) CA-2 (berkeley.edu) (CA) CA-2.1 (eecs.berkeley.edu) – Provide assurance that a particular public key belongs to a specific entity September 26, 2005 CS161 Fall 2005 9 September 26, 2005 CS161 Fall 2005 10 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner Digital Certificate Chain Browsers Include Root CA Certificates Anthony’s Digital Certificate UCB EECS’ Digital Cert Tools? Options ? Advanced ? View Certs Name: Anthony Joseph Name: UCB EECS Public Key: 0xABCD12345 Public Key: 0xEF67890B Signed by Signed by UCB EECS UCB Verisign CA’s Digital Cert UCB’s Digital Certificate Name: Verisign CA Name: UCB Public Key: 0xBCD012345 Public Key: 0x98765432 Signed by Signed by Verisign Verisign September 26, 2005 CA CS161 Fall 2005 CA 11 September 26, 2005 CS161 Fall 2005 12 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner 2 PKI Example: Creating Certs PKI Example: Getting Keys 1. Alice generates her own key pair 4. Alice gets Bob’s public key from the CA private key public key Alice Alice private key public Bobkey 2. Bob generates his own key pair Alice private key public key Bob Bob 5. Bob gets Alice’s public key from the CA public key Alice 3. Both send their public key to a CA and private key receive a public key certificate signed by CA Bob September 26, 2005 CS161 Fall 2005 13 September 26, 2005 CS161 Fall 2005 14 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner PKI Example: Secure Channel Secure Channel: Choice #2 5. Alice uses private key to encrypt and sign: Auth authentication, confidentiality, integrity server Alice Recall: Asymmetric cryptosystem Bob KB KA is expensive! ? Use only Alice for authentication and Public Bob Alice symmetric key exchange Alice Private Message Sign Hash Hash and compare Message • Use a trusted third-party authentication Encryption Decryption server and symmetric key cryptography for authentication, integrity, and confidentiality Bob Bob Public Private • Users share secret key with auth server September 26, 2005 CS161 Fall 2005 15 September 26, 2005 CS161 Fall 2005 16 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner Third-Party Authentication Authentication Choices Hi Bob! I’m Alice, Here’s N L KAB • Both require a trusted third-party server Auth Hi Bob! I’m Alice, server • Both require wide-spread deployment of Here’s N L K AB server infrastructure KB KA • Still have distribution problem Bob Alice – Root certificates versus shared secrets • Alice constructs a secure channel to auth server • Difference is use of public/private key • Alice sends secret key message for Bob cryptosystem versus private/shared key one – Also includes nonce and session key lifetime - Why? • Another alternative: • Server constructs secure channel to Bob • Server forwards message – Pretty Good Privacy (more later on) September 26, 2005 CS161 Fall 2005 17 September 26, 2005 CS161 Fall 2005 18 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner 3 Three Concrete Examples Pretty Good Privacy (PGP) • Pretty Good Privacy (PGP) • Provides • Transport Layer Security (TLS) – Authentication, Confidentiality, Integrity (optional) • Virtual Private Networks (VPN) • Application examples: file transfers, e-mail • Weaker authentication than PKI, but – Freely available: standalone and plug-ins for many e-mail clients – Not controlled by a government or standard organization September 26, 2005 CS161 Fall 2005 19 September 26, 2005 CS161 Fall 2005 20 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner PGP Services PGP: Public Key Management • Authentication • No rigid public key management scheme – Digital signature; uses DSS/SHA or RSA/SHA • Problem: how to reliably get public key • Confidentiality – Possible solution: physically (secure but unpractical) or by phone – Encryption (triple DES or RSA) • PGP solution: build a “web of trust” • Integrity – Let’s assume you know several variably trusted users – Optional digital signature on entire message – Each of these indvidual can sign certificates for other users • Also provides – Each signature has an associated trust field indicating – Compression è Zip the level of trust in the certificate September– E 26,-mail 2005 compatibilityCS161 èFall 2005Radix-64 conversion 21 September 26, 2005 CS161 Fall 2005 22 – Large file supportJoseph/Tygar/Vazirani/Wagner è Segmentation Joseph/Tygar/Vazirani/Wagner Transport Layer Security (TLS) • Follow on to Secure Socket Layer (SSLv3) • Often used for secure HTTP web browsing – HTTPS (HTTP over SSL over TCP), SMTP, and NNTP [https://bearfacts.berkeley.edu/] – Stunnel standalone program tunnels any TCP traffic • Steps: 1. Negotiate algorithm choices for authentication and bulk data transfer 2. Use public key encryption-based key exchange or certificate-based authentication 3. Encrypt stream with symmetric cipher • MAC and optional compression September 26, 2005 CS161 Fall 2005 23 September 26, 2005 CS161 Fall 2005 24 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner 4 Virtual Private Network (VPN) VPN Implementations Yoyodyne Corp VPN server • Typically a virtual network driver that Internet User forwards traffic over a secure channel Branch Office – Many commercial clients for PCs Yahoo – Open source client: OpenVPN • Often need to provide secure remote access to a – Commercial hardware available for network protected by a firewall performance or networks – Remote access, telecommuting, branch offices, … • Software clients use IPSEC or TLS/SSL • VPN tunnels all or some traffic from a machine or network to another network • Try it for yourself! – Provides Authentication, Confidentiality, Integrity – http://www.net.berkeley.edu/vpn/ September 26, 2005 CS161 Fall 2005 25 September 26, 2005 CS161 Fall 2005 26 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner VPN Perimeter Security Issues VPN Perimeter Security Issues • Slammer worm penetrates • A VPN enables access to servers unsecured network of a – That’s the goal! D-B contractor • But, if remote machine or network is • Squirms through a VPN compromised, attacker gains access to the into D-B's internal network servers • Disables safety monitoring – Same as if they were inside building system for ~5hrs Ohio's Davis-Besse • Defeats physical and network security • Plant was already offline • Analog systems still online Nuclear Power Plant (Jan 2003) SecurityFocus 08/19/03 September 26, 2005 CS161 Fall 2005 27 September 26, 2005 CS161 Fall 2005 28 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner 5.
Recommended publications
  • A Focus on S/MIME

    A Focus on S/MIME

    The University of Saskatchewan Department of Computer Science Technical Report #2011-03 Cryptographic Security for Emails: A Focus on S/MIME Minhaz Fahim Zibran Department of Computer Science University of Saskatchewan Email: [email protected] Abstract In this paper I present a study on \S/MIME", which has become the industry standard for secure email exchange. Based on existing literature review, the study examines S/MIME in depth with specific emphasis on its architecture, strengths, and deficiencies. The study also identifies usability issues related to S/MIME enabled email clients, which indicate scopes for further improvements in those implementations. Obstacles in the adoption of S/MIME are also identified indicating what is required for its successful adoption in the community. In presenting the study, the paper contributes in two ways: (a) for any newcomer in the field of cryptography this paper will be a useful resource to quickly learn about S/MIME in a fair level of detail, (b) the indication about limitations of S/MIME and its implementations reveals an avenue for further research in the area of email security, which may result in improvement of S/MIME itself, or its implementations in the email clients. Keywords: Email Security, S/MIME, MIME, PGP, PKI, Certificate, Email Authentication, Email Encryption, Key Management 1 Introduction Email has been a very common medium of communication these days. It somewhat re- places the traditional surface mail and many of the traditional ways of communication [32]. Today people send and read emails from their personal computers, business workstation, PDAs and even cell phones.
  • Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation

    Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation

    Not-quite-so-broken TLS Lessons in re-engineering a security protocol specification and implementation David Kaloper Meršinjak Hannes Mehnert Peter Sewell Anil Madhavapeddy University of Cambridge, Computer Labs Usenix Security, Washington DC, 12 August 2015 INT SSL23_GET_CLIENT_HELLO(SSL *S) { CHAR BUF_SPACE[11]; /* REQUEST THIS MANY BYTES IN INITIAL READ. * WE CAN DETECT SSL 3.0/TLS 1.0 CLIENT HELLOS * ('TYPE == 3') CORRECTLY ONLY WHEN THE FOLLOWING * IS IN A SINGLE RECORD, WHICH IS NOT GUARANTEED BY * THE PROTOCOL SPECIFICATION: * BYTE CONTENT * 0 TYPE \ * 1/2 VERSION > RECORD HEADER * 3/4 LENGTH / * 5 MSG_TYPE \ * 6-8 LENGTH > CLIENT HELLO MESSAGE Common CVE sources in 2014 Class # Memory safety 15 State-machine errors 10 Certificate validation 5 ASN.1 parsing 3 (OpenSSL, GnuTLS, SecureTransport, Secure Channel, NSS, JSSE) Root causes Error-prone languages Lack of separation Ambiguous and untestable specification nqsb approach Choice of language and idioms Separation and modular structure A precise and testable specification of TLS Reuse between specification and implementation Choice of language and idioms OCaml: a memory-safe language with expressive static type system Well contained side-effects Explicit flows of data Value-based Explicit error handling We leverage it for abstraction and automated resource management. Formal approaches Either reason about a simplified model of the protocol; or reason about small parts of OpenSSL. In contrast, we are engineering a deployable implementation. nqsb-tls A TLS stack, developed from scratch, with dual goals: Executable specification Usable TLS implementation Structure nqsb-TLS ML module layout Core Is purely functional: VAL HANDLE_TLS : STATE -> BUFFER -> [ `OK OF STATE * BUFFER OPTION * BUFFER OPTION | `FAIL OF FAILURE ] Core OCaml helps to enforce state-machine invariants.
  • The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)?

    The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)?

    The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)? Hugo Krawczyk?? Abstract. We study the question of how to generically compose sym- metric encryption and authentication when building \secure channels" for the protection of communications over insecure networks. We show that any secure channels protocol designed to work with any combina- tion of secure encryption (against chosen plaintext attacks) and secure MAC must use the encrypt-then-authenticate method. We demonstrate this by showing that the other common methods of composing encryp- tion and authentication, including the authenticate-then-encrypt method used in SSL, are not generically secure. We show an example of an en- cryption function that provides (Shannon's) perfect secrecy but when combined with any MAC function under the authenticate-then-encrypt method yields a totally insecure protocol (for example, ¯nding passwords or credit card numbers transmitted under the protection of such protocol becomes an easy task for an active attacker). The same applies to the encrypt-and-authenticate method used in SSH. On the positive side we show that the authenticate-then-encrypt method is secure if the encryption method in use is either CBC mode (with an underlying secure block cipher) or a stream cipher (that xor the data with a random or pseudorandom pad). Thus, while we show the generic security of SSL to be broken, the current practical implementations of the protocol that use the above modes of encryption are safe. 1 Introduction The most widespread application of cryptography in the Internet these days is for implementing a secure channel between two end points and then exchanging information over that channel.
  • Multi-Device for Signal

    Multi-Device for Signal

    Multi-Device for Signal S´ebastienCampion3, Julien Devigne1, C´elineDuguey1;2, and Pierre-Alain Fouque2 1 DGA Maˆıtrisede l’information, Bruz, France [email protected] 2 Irisa, Rennes, France, [email protected], [email protected] Abstract. Nowadays, we spend our life juggling with many devices such as smartphones, tablets or laptops, and we expect to easily and efficiently switch between them without losing time or security. However, most ap- plications have been designed for single device usage. This is the case for secure instant messaging (SIM) services based on the Signal proto- col, that implements the Double Ratchet key exchange algorithm. While some adaptations, like the Sesame protocol released by the developers of Signal, have been proposed to fix this usability issue, they have not been designed as specific multi-device solutions and no security model has been formally defined either. In addition, even though the group key exchange problematic appears related to the multi-device case, group solutions are too generic and do not take into account some properties of the multi-device setting. Indeed, the fact that all devices belong to a single user can be exploited to build more efficient solutions. In this paper, we propose a Multi-Device Instant Messaging protocol based on Signal, ensuring all the security properties of the original Signal. Keywords: cryptography, secure instant messaging, ratchet, multi-device 1 Introduction 1.1 Context Over the last years, secure instant messaging has become a key application ac- cessible on smartphones. In parallel, more and more people started using several devices - a smartphone, a tablet or a laptop - to communicate.
  • A Novel Asymmetric Hyperchaotic Image Encryption Scheme Based on Elliptic Curve Cryptography

    A Novel Asymmetric Hyperchaotic Image Encryption Scheme Based on Elliptic Curve Cryptography

    applied sciences Article A Novel Asymmetric Hyperchaotic Image Encryption Scheme Based on Elliptic Curve Cryptography Haotian Liang , Guidong Zhang *, Wenjin Hou, Pinyi Huang, Bo Liu and Shouliang Li * School of Information Science and Engineering, Lanzhou University, Lanzhou 730000, China; [email protected] (H.L.); [email protected] (W.H.); [email protected] (P.H.); [email protected] (B.L.) * Correspondence: [email protected] (G.Z.); [email protected] (S.L.); Tel.: +86-185-0948-7799 (S.L.) Abstract: Most of the image encryption schemes based on chaos have so far employed symmetric key cryptography, which leads to a situation where the key cannot be transmitted in public channels, thus limiting their extended application. Based on the elliptic curve cryptography (ECC), we proposed a public key image encryption method where the hash value derived from the plain image was encrypted by ECC. Furthermore, during image permutation, a novel algorithm based on different- sized block was proposed. The plain image was firstly divided into five planes according to the amount of information contained in different bits: the combination of the low 4 bits, and other four planes of high 4 bits respectively. Second, for different planes, the corresponding method of block partition was followed by the rule that the higher the bit plane, the smaller the size of the partitioned block as a basic unit for permutation. In the diffusion phase, the used hyperchaotic sequences in permutation were applied to improve the efficiency. Lots of experimental simulations and cryptanalyses were implemented in which the NPCR and UACI are 99.6124% and 33.4600% Citation: Liang, H.; Zhang, G.; Hou, respectively, which all suggested that it can effectively resist statistical analysis attacks and chosen W.; Huang, P.; Liu, B.; Li, S.
  • Towards a Hybrid Public Key Infrastructure (PKI): a Review

    Towards a Hybrid Public Key Infrastructure (PKI): a Review

    Towards a Hybrid Public Key Infrastructure (PKI): A Review Priyadarshi Singh, Abdul Basit, N Chaitanya Kumar, and V. Ch. Venkaiah School of Computer and Information Sciences, University of Hyderabad, Hyderabad-500046, India Abstract. Traditional Certificate- based public key infrastructure (PKI) suffers from the problem of certificate overhead like its storage, verification, revocation etc. To overcome these problems, idea of certificate less identity-based public key cryptography (ID-PKC) was proposed by Shamir. This is suitable for closed trusted group only. Also, this concept has some inherent problems like key escrow problem, secure key channel problem, identity management overhead etc. Later on, there had been several works which tried to combine both the cryptographic techniques such that the resulting hybrid PKI framework is built upon the best features of both the cryptographic techniques. It had been shown that this approach solves many problems associated with an individual cryptosystem. In this paper, we have reviewed and compared such hybrid schemes which tried to combine both the certificate based PKC and ID-based PKC. Also, the summary of the comparison, based on various features, is presented in a table. Keywords: Certificate-based PKI; Identity-based public key cryptography (ID-PKC); Hybrid PKI 1 INTRODUCTION Public key infrastructure (PKI) and public key cryptography (PKC) [12] plays a vital role with four major components of digital security: authentication, integrity, confidentiality and non-repudiation. Infact, PKI enables the use of PKC through key management. The ”efficient and secure management of the key pairs during their whole life cycle" is the purpose of PKI, which involves key generation, key distribution, key renewal, key revocation etc [11].
  • Security Target Document

    Security Target Document

    Security Target Document Passport Certificate Server Ver. 4.1.1 Prepared for: Common Criteria EAL2 (augmented) 30 April 2002 2225 Sheppard Ave, Suite 1700 Toronto, Ontario, Canada M2J 5C2 TEL: 416-756-2324 FAX: 416-756-7346 [email protected] www.dvnet.com Passport Certificate Server V.4.1.1 Security Target 30 April 2002 Common Criteria EAL 2 (augmented) Version 1.00 TABLE OF CONTENTS 1 Introduction ............................................................................................................................................ 1 1.1 Security Target Identification......................................................................................................... 1 1.2 Security Target Overview............................................................................................................... 1 1.3 Common Criteria Conformance .....................................................................................................1 2 TOE Description..................................................................................................................................... 2 2.1 Product Deployment....................................................................................................................... 2 2.2 Product Functions........................................................................................................................... 2 2.3 Product Description ........................................................................................................................ 3 2.3.1 Platform
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019

    Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019

    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
  • Trivia: a Fast and Secure Authenticated Encryption Scheme

    Trivia: a Fast and Secure Authenticated Encryption Scheme

    TriviA: A Fast and Secure Authenticated Encryption Scheme Avik Chakraborti1, Anupam Chattopadhyay2, Muhammad Hassan3, and Mridul Nandi1 1 Indian Statistical Institute, Kolkata, India [email protected], [email protected] 2 School of Computer Engineering, NTU, Singapore [email protected] 3 RWTH Aachen University, Germany [email protected] Abstract. In this paper, we propose a new hardware friendly authen- ticated encryption (AE) scheme TriviA based on (i) a stream cipher for generating keys for the ciphertext and the tag, and (ii) a pairwise in- dependent hash to compute the tag. We have adopted one of the ISO- standardized stream ciphers for lightweight cryptography, namely Triv- ium, to obtain our underlying stream cipher. This new stream cipher has a state that is a little larger than the state of Trivium to accommodate a 128-bit secret key and IV. Our pairwise independent hash is also an adaptation of the EHC or \Encode-Hash-Combine" hash, that requires the optimum number of field multiplications and hence requires small hardware footprint. We have implemented the design in synthesizable RTL. Pre-layout synthesis, using 65 nm standard cell technology under typical operating conditions, reveals that TriviA is able to achieve a high throughput of 91:2 Gbps for an area of 24:4 KGE. We prove that our construction has at least 128-bit security for privacy and 124-bit security of authenticity under the assumption that the underlying stream cipher produces a pseudorandom bit stream. Keywords: Trivium, stream cipher, authenticated encryption, pairwise independent, EHC, TriviA. 1 Introduction The emergence of Internet-of-Things (IoT) has made security an extremely im- portant design goal.
  • Cryptanalysis of Globalplatform Secure Channel Protocols

    Cryptanalysis of Globalplatform Secure Channel Protocols

    Cryptanalysis of GlobalPlatform Secure Channel Protocols Mohamed Sabt1;2, Jacques Traor´e1 1 Orange Labs, 42 rue des coutures, 14066 Caen, France fmohamed.sabt, [email protected] 2 Sorbonne universit´es,Universit´ede technologie de Compi`egne, Heudiasyc, Centre de recherche Royallieu, 60203 Compi`egne,France Abstract. GlobalPlatform (GP) card specifications are the de facto standards for the industry of smart cards. Being highly sensitive, GP specifications were defined regarding stringent security requirements. In this paper, we analyze the cryptographic core of these requirements; i.e. the family of Secure Channel Protocols (SCP). Our main results are twofold. First, we demonstrate a theoretical attack against SCP02, which is the most popular protocol in the SCP family. We discuss the scope of our attack by presenting an actual scenario in which a malicious entity can exploit it in order to recover encrypted messages. Second, we inves- tigate the security of SCP03 that was introduced as an amendment in 2009. We find that it provably satisfies strong notions of security. Of par- ticular interest, we prove that SCP03 withstands algorithm substitution attacks (ASAs) defined by Bellare et al. that may lead to secret mass surveillance. Our findings highlight the great value of the paradigm of provable security for standards and certification, since unlike extensive evaluation, it formally guarantees the absence of security flaws. Keywords: GlobalPlatform, secure channel protocol, provable security, plaintext recovery, stateful encryption 1 Introduction Nowadays, smart cards are already playing an important role in the area of in- formation technology. Considered to be tamper resistant, they are increasingly used to provide security services [38].
  • The RSA Algorithm

    The RSA Algorithm

    The RSA Algorithm Evgeny Milanov 3 June 2009 In 1978, Ron Rivest, Adi Shamir, and Leonard Adleman introduced a cryptographic algorithm, which was essentially to replace the less secure National Bureau of Standards (NBS) algorithm. Most impor- tantly, RSA implements a public-key cryptosystem, as well as digital signatures. RSA is motivated by the published works of Diffie and Hellman from several years before, who described the idea of such an algorithm, but never truly developed it. Introduced at the time when the era of electronic email was expected to soon arise, RSA implemented two important ideas: 1. Public-key encryption. This idea omits the need for a \courier" to deliver keys to recipients over another secure channel before transmitting the originally-intended message. In RSA, encryption keys are public, while the decryption keys are not, so only the person with the correct decryption key can decipher an encrypted message. Everyone has their own encryption and decryption keys. The keys must be made in such a way that the decryption key may not be easily deduced from the public encryption key. 2. Digital signatures. The receiver may need to verify that a transmitted message actually origi- nated from the sender (signature), and didn't just come from there (authentication). This is done using the sender's decryption key, and the signature can later be verified by anyone, using the corresponding public encryption key. Signatures therefore cannot be forged. Also, no signer can later deny having signed the message. This is not only useful for electronic mail, but for other electronic transactions and transmissions, such as fund transfers.
  • A Practical Evaluation of a High-Security Energy-Efficient

    A Practical Evaluation of a High-Security Energy-Efficient

    sensors Article A Practical Evaluation of a High-Security Energy-Efficient Gateway for IoT Fog Computing Applications Manuel Suárez-Albela * , Tiago M. Fernández-Caramés , Paula Fraga-Lamas and Luis Castedo Department Computer Engineering, Faculty of Computer Science, Universidade da Coruña, 15071 A Coruña, Spain; [email protected] (T.M.F.-C.); [email protected] (P.F.-L.); [email protected] (L.C.) * Correspondence: [email protected]; Tel.: +34-981-167-000 (ext. 6051) Received: 28 July 2017; Accepted: 19 August 2017; Published: 29 August 2017 Abstract: Fog computing extends cloud computing to the edge of a network enabling new Internet of Things (IoT) applications and services, which may involve critical data that require privacy and security. In an IoT fog computing system, three elements can be distinguished: IoT nodes that collect data, the cloud, and interconnected IoT gateways that exchange messages with the IoT nodes and with the cloud. This article focuses on securing IoT gateways, which are assumed to be constrained in terms of computational resources, but that are able to offload some processing from the cloud and to reduce the latency in the responses to the IoT nodes. However, it is usually taken for granted that IoT gateways have direct access to the electrical grid, which is not always the case: in mission-critical applications like natural disaster relief or environmental monitoring, it is common to deploy IoT nodes and gateways in large areas where electricity comes from solar or wind energy that charge the batteries that power every device. In this article, how to secure IoT gateway communications while minimizing power consumption is analyzed.