FIDO Technical Glossary
Total Page：16
File Type：pdf, Size：1020Kb
Load more
Recommended publications
-
Efficient Implementation of Elliptic Curve Cryptography in Reconfigurable Hardware
EFFICIENT IMPLEMENTATION OF ELLIPTIC CURVE CRYPTOGRAPHY IN RECONFIGURABLE HARDWARE by E-JEN LIEN Submitted in partial fulfillment of the requirements for the degree of Master of Science Thesis Advisor: Dr. Swarup Bhunia Department of Electrical Engineering and Computer Science CASE WESTERN RESERVE UNIVERSITY May, 2012 CASE WESTERN RESERVE UNIVERSITY SCHOOL OF GRADUATE STUDIES We hereby approve the thesis/dissertation of _____________________________________________________E-Jen Lien candidate for the ______________________degreeMaster of Science *. Swarup Bhunia (signed)_______________________________________________ (chair of the committee) Christos Papachristou ________________________________________________ Frank Merat ________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________ (date) _______________________03/19/2012 *We also certify that written approval has been obtained for any proprietary material contained therein. To my family ⋯ Contents List of Tables iii List of Figures v Acknowledgements vi List of Abbreviations vii Abstract viii 1 Introduction 1 1.1 Research objectives . .1 1.2 Thesis Outline . .3 1.3 Contributions . .4 2 Background and Motivation 6 2.1 MBC Architecture . .6 2.2 Application Mapping to MBC . .7 2.3 FPGA . .9 2.4 Mathematical Preliminary . 10 2.5 Elliptic Curve Cryptography . 10 2.6 Motivation . 16 i 3 Design Principles and Methodology 18 3.1 Curves over Prime Field . 18 3.2 Curves over Binary Field . 25 3.3 Software Code for ECC . 31 3.4 RTL code for FPGA design . 31 3.5 Input Data Flow Graph (DFG) for MBC . 31 4 Implementation of ECC 32 4.1 Software Implementation . 32 4.1.1 Prime Field . 33 4.1.2 Binary Field . 34 4.2 Implementation in FPGA . 35 4.2.1 Prime Field . 36 4.2.2 Binary Field . -
Specification for JSON Abstract Data Notation Version
Standards Track Work Product Specification for JSON Abstract Data Notation (JADN) Version 1.0 Committee Specification 01 17 August 2021 This stage: https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.md (Authoritative) https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.html https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.pdf Previous stage: https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.md (Authoritative) https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.html https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.pdf Latest stage: https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.md (Authoritative) https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.html https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.pdf Technical Committee: OASIS Open Command and Control (OpenC2) TC Chair: Duncan Sparrell ([email protected]), sFractal Consulting LLC Editor: David Kemp ([email protected]), National Security Agency Additional artifacts: This prose specification is one component of a Work Product that also includes: JSON schema for JADN documents: https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/schemas/jadn-v1.0.json JADN schema for JADN documents: https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/schemas/jadn-v1.0.jadn Abstract: JSON Abstract Data Notation (JADN) is a UML-based information modeling language that defines data structure independently of data format. -
CHERI Instruction-Set Architecture
UCAM-CL-TR-876 Technical Report ISSN 1476-2986 Number 876 Computer Laboratory Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son September 2015 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2015 Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son, SRI International Approved for public release; distribution is unlimited. Sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C-0237 (“CTSRD”) and FA8750-11-C-0249 (“MRC2”) as part of the DARPA CRASH and DARPA MRC research programs. The views, opinions, and/or findings contained in this report are those of the authors and should not be interpreted as representing the official views or policies, either expressed or implied, of the Department of Defense or the U.S. Government. Additional support was received from St John’s College Cambridge, the SOAAP Google Focused Research Award, the RCUK’s Horizon Digital Economy Research Hub Grant (EP/G065802/1), the EPSRC REMS Programme Grant (EP/K008528/1), the Isaac Newton Trust, the UK Higher Education Innovation Fund (HEIF), and Thales E-Security. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Abstract This technical report describes CHERI ISAv4, the fourth version of the Capability Hardware Enhanced RISC Instructions (CHERI) Instruction-Set Architecture (ISA)1 being developed by SRI International and the University of Cambridge. -
A High-Speed Constant-Time Hardware Implementation of Ntruencrypt SVES
A High-Speed Constant-Time Hardware Implementation of NTRUEncrypt SVES Farnoud Farahmand, Malik Umar Sharif, Kevin Briggs, Kris Gaj Department of Electrical and Computer Engineering, George Mason University, Fairfax, VA, U.S.A. fffarahma, msharif2, kbriggs2, [email protected] process a year later. Among the candidates, there are new, Abstract—In this paper, we present a high-speed constant- substantially modified versions of NTRUEncrypt. However, in time hardware implementation of NTRUEncrypt Short Vector an attempt to characterize an already standardized algorithm, Encryption Scheme (SVES), fully compliant with the IEEE 1363.1 Standard Specification for Public Key Cryptographic Techniques in this paper, we focus on the still unbroken version of the Based on Hard Problems over Lattices. Our implementation algorithm published in 2008. We are not aware of any previous follows an earlier proposed Post-Quantum Cryptography (PQC) high-speed hardware implementation of the entire NTRUEn- Hardware Application Programming Interface (API), which crypt SVES scheme reported in the scientific literature or facilitates its fair comparison with implementations of other available commercially. Our implementation is also unique in PQC schemes. The paper contains the detailed flow and block diagrams, timing analysis, as well as results in terms of latency (in that it is the first implementation of any PQC scheme following clock cycles), maximum clock frequency, and resource utilization our newly proposed PQC Hardware API [3]. As such, it in modern high-performance Field Programmable Gate Arrays provides a valuable reference for any future implementers of (FPGAs). Our design takes full advantage of the ability to paral- PQC schemes, which is very important in the context of the lelize the major operation of NTRU, polynomial multiplication, in ongoing NIST standard candidate evaluation process. -
Understanding JSON Schema Release 2020-12
Understanding JSON Schema Release 2020-12 Michael Droettboom, et al Space Telescope Science Institute Sep 14, 2021 Contents 1 Conventions used in this book3 1.1 Language-specific notes.........................................3 1.2 Draft-specific notes............................................4 1.3 Examples.................................................4 2 What is a schema? 7 3 The basics 11 3.1 Hello, World!............................................... 11 3.2 The type keyword............................................ 12 3.3 Declaring a JSON Schema........................................ 13 3.4 Declaring a unique identifier....................................... 13 4 JSON Schema Reference 15 4.1 Type-specific keywords......................................... 15 4.2 string................................................... 17 4.2.1 Length.............................................. 19 4.2.2 Regular Expressions...................................... 19 4.2.3 Format.............................................. 20 4.3 Regular Expressions........................................... 22 4.3.1 Example............................................. 23 4.4 Numeric types.............................................. 23 4.4.1 integer.............................................. 24 4.4.2 number............................................. 25 4.4.3 Multiples............................................ 26 4.4.4 Range.............................................. 26 4.5 object................................................... 29 4.5.1 Properties........................................... -
Efficient Sorting of Search Results by String Attributes
Efficient sorting of search results by string attributes Nicholas Sherlock Andrew Trotman Department of Computer Science Department of Computer Science University of Otago University of Otago Otago 9054 New Zealand Otago 9054 New Zealand [email protected] [email protected] Abstract It is sometimes required to order search In addition, the search engine must allocate memory results using textual document attributes such as to an index structure which allows it to efficiently re- titles. This is problematic for performance because trieve those post titles by document index, which, using of the memory required to store these long text a simplistic scheme with 4 bytes required per docu- strings at indexing and search time. We create a ment offset, would require an additional 50 megabytes method for compressing strings which may be used of storage. for approximate ordering of search results on textual For search terms which occur in many documents, attributes. We create a metric for analyzing its most of the memory allocated to storing text fields like performance. We then use this metric to show that, post titles must be examined during result list sorting. for document collections containing tens of millions of As 550 megabytes is vastly larger than the cache mem- documents, we can sort document titles using 64-bits ory available inside the CPU, sorting the list of docu- of storage per title to within 100 positions of error per ments by post title requires the CPU to load that data document. from main memory, which adds substantial latency to query processing and competes for memory bandwidth Keywords Information Retrieval, Web Documents, with other processes running on the same system. -
![[MS-LISTSWS]: Lists Web Service Protocol](https://docslib.b-cdn.net/cover/4928/ms-listsws-lists-web-service-protocol-534928.webp)
[MS-LISTSWS]: Lists Web Service Protocol
[MS-LISTSWS]: Lists Web Service Protocol Intellectual Property Rights Notice for Open Specifications Documentation . Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions. Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting [email protected]. -
V10.5.0 (2013-07)
ETSI TS 126 234 V10.5.0 (2013-07) Technical Specification Universal Mobile Telecommunications System (UMTS); LTE; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs (3GPP TS 26.234 version 10.5.0 Release 10) 3GPP TS 26.234 version 10.5.0 Release 10 1 ETSI TS 126 234 V10.5.0 (2013-07) Reference RTS/TSGS-0426234va50 Keywords LTE,UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. -
White-Box Implementation of the Identity-Based Signature Scheme in the IEEE P1363 Standard for Public Key Cryptography
IEICE TRANS. INF. & SYST., VOL.E103–D, NO.2 FEBRUARY 2020 188 INVITED PAPER Special Section on Security, Privacy, Anonymity and Trust in Cyberspace Computing and Communications White-Box Implementation of the Identity-Based Signature Scheme in the IEEE P1363 Standard for Public Key Cryptography Yudi ZHANG†,††, Debiao HE†,††a), Xinyi HUANG†††,††††, Ding WANG††,†††††, Kim-Kwang Raymond CHOO††††††, Nonmembers, and Jing WANG†,††, Student Member SUMMARY Unlike black-box cryptography, an adversary in a white- box security model has full access to the implementation of the crypto- graphic algorithm. Thus, white-box implementation of cryptographic algo- rithms is more practical. Nevertheless, in recent years, there is no white- box implementation for public key cryptography. In this paper, we propose Fig. 1 A typical DRM architecture the first white-box implementation of the identity-based signature scheme in the IEEE P1363 standard. Our main idea is to hide the private key to multiple lookup tables, so that the private key cannot be leaked during the algorithm executed in the untrusted environment. We prove its security in both black-box and white-box models. We also evaluate the performance gram. However, the adversary does not have the permis- of our white-box implementations, in order to demonstrate utility for real- sion to access the internal process of the program’s execu- world applications. tion. In practice, an adversary can also observe and mod- key words: white-box implementation, white-box security, IEEE P1363, ify the algorithm’s implementation to obtain the internal de- identity-based signature, key extraction tails, such as the secret key. -
IEEE P1363.3 Standard Specifications for Public Key Cryptography
IEEE P1363.3 D1 IBKAS January 29, 2008 IEEE P1363.3 Standard Specifications for Public Key Cryptography: Identity Based Key Agreement Scheme (IBKAS) Abstract. This document specifies pairing based, identity based, and authenticated key agreement techniques. One of the advantages of Identity Based key agreement techniques is that there is no public key transmission and verification needed. Contents 1. DEFINITIONS ......................................................................................................................................... 2 2. TYPES OF CRYPTOGRAPHIC TECHNIQUES ................................................................................ 2 2.1 GENERAL MODEL .................................................................................................................................. 2 2.2 PRIMITIVES............................................................................................................................................ 2 2.3 SCHEMES ............................................................................................................................................... 3 2.4 ADDITIONAL METHODS ......................................................................................................................... 3 2.5 TABLE SUMMARY.................................................................................................................................. 3 3. PRIMITIVES FOR IDENTITY BASED KEY AGREEMENT PROBLEM...................................... 4 3.1 PRIMITIVES BORROWED FROM -
IEEE P1363.2: Password-Based Cryptography
IEEE P1363.2: Password-based Cryptography David Jablon CTO, Phoenix Technologies NIST PKI TWG - July 30, 2003 What is IEEE P1363.2? • “Standard Specification for Password-Based Public-Key Cryptographic Techniques” • Proposed standard • Companion to IEEE Std 1363-2000 • Product of P1363 Working Group • Open standards process PKI TWG July 2003 IEEE P1363.2: Password-based Cryptography 2 One of several IEEE 1363 standards • Std 1363-2000 • Sign, Encrypt, Key agreem’t, using IF, DL, & EC families • P1363a • Same goals & families as 1363-2000 • P1363.1: Lattice family • Same goals as 1363-2000, Different family • P1363.2: Password-based • Same families • More ambitious goals PKI TWG July 2003 IEEE P1363.2: Password-based Cryptography 3 Scope of P1363.2 • Modern “zero knowledge” password methods • Uses public key techniques • Uses two or more parties • Needs no other infrastructure • Authenticated key establishment • Resists attack on low-grade secrets • passwords, password-derived keys, PINs, ... PKI TWG July 2003 IEEE P1363.2: Password-based Cryptography 4 Rationale (1) • Why low-grade secrets? • People have trouble with high-grade keys • storage -- memorizing • input -- attention to detail • output -- typing • Passwords are ubiquitous • Easy for people to memorize, recognize, and type. • Reduce security/convenience tradeoffs. PKI TWG July 2003 IEEE P1363.2: Password-based Cryptography 5 Rationale (2) • Why use public-key techniques? • Symmetric methods can’t do it. • Why new methods? • Different than symmetric, hash, or other PK crypto. • AES, SHA-1, DH, and RSA can’t do it alone. PKI TWG July 2003 IEEE P1363.2: Password-based Cryptography 6 Chosen Password Quality Summarized from Distribution Morris & Thompson ‘79, Klein ‘90, Spafford ‘92 0 30 or so 60 or so Password Entropy (bits) History of protocols that fail to dictionary attack (or worse) • Clear text password π • Password as a key Eπ (verifiable text) • (e.g. -
Discretionary Access Control
Part IV Access Control Confidentiality and integrity are often enforced using a form of authorization known as access control, which involves the following assumptions. • Predefined operations are the sole means by which principals can learn or update information. • A reference monitor is consulted whenever one of these predefined oper- ations is invoked; the operation is allowed to proceed only if the invoker holds the required privileges. Confidentiality then is achieved by restricting whether a given principal is au- thorized to execute operations that reveal information; integrity is achieved by restricting execution of operations that perform updates. An access control policy specifies which of the operations associated with any given object (including operations to change the policy) each given principal1 is authorized to have performed. Principals are entities to which execution can be attributed|users, processes, threads, or even procedure activations. Ob- jects are entities on which operations are defined—storage abstractions, such as memory or files (with read, write, and execute operations), and code ab- stractions, such as modules or services (with operations to initiate or suspend execution). Distinct privileges are typically associated with distinct operations, and sometimes there are distinct privileges for each different operation on each different object. So, for example, there might be a specific privilege readObj that a principal must hold to perform operation read on object Obj. The Principle of Least Privilege is best served by having fine-grained princi- pals, objects, and operations; the Principle of Failsafe Defaults favors defining an access control policy by enumerating privileges rather than prohibitions. That, however, is only a small part of the picture, and there is much ground to cover in our discussions of access control policy.