BUILDING BLOCKS

Data integrity

Hash chain
non-repudiable probe of data chronology
doc1 → hash → has1 ─┬→ hash → has2 ─┬→ hash → has3 ─┬→ hash
               doc2─┘         doc3 ─┘         doc4 ─┘
ºMerkle treeº
@[https://en.wikipedia.org/wiki/Merkle_tree]
- Allows to check if a leaf (data) is part of the tree with just a
  subset of the tree
- NOTE: In blockchain leafs are transactions and the tree is a block


- TODO:
  ºPatricia Treeº (Used by Ethereum,...)

Secret sharing
@[https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing]
- provides a method of secret sharing, where a secret is divided into parts,
  giving each participant its own unique part, where some of the parts or all
  of them are needed in order to reconstruct the secret.
   Counting on all participants to combine the secret might be impractical, and
   therefore sometimes the threshold scheme is used where any "k" of the parts
   are sufficient to reconstruct the original secret
  The essential idea of Adi Shamir's threshold scheme is that 2 points are
   sufficient to define a line, 3 points are sufficient to define a parabola, 4
   points to define a cubic curve and so forth. That is, it takes k points to
   define a polynomial of degree k − 1

(Remote)Authentication

Challenge-response
- cryptographic primitive
- Used mostly in communication protocols.
- Authentication server encrypts a challenge
  (typically a random number) with a public key.
  The device proves it possesses a copy of the
  matching private key by providing the decrypted
  challenge.

Authenticated Encryption (AE)
AE with associated data(AEAD)


- The need for AE emerged from the observation that securely combining
   separate confidentiality and authentication block cipher operation modes
   could be error prone and difficult confirmed by a number of practical
   attacks introduced into production protocols and applications by
   incorrect implementation, or lack, of authentication (including SSL/TLS)
- A typical programming interface for AE mode implementation would provide the following functions:

 Encryption
     Input : plaintext, key, and optionally a header in plaintext that will not
             be encrypted, but will be covered by authenticity protection.
     Output: ciphertext and authentication tag (message authentication code).
 Decryption
     Input : ciphertext, key, authentication tag, and optionally a header.
     Output: plaintext, or an error if the authentication tag does not match
             the supplied ciphertext or header.

- Approaches to authenticated encryption:
  - Encrypt-then-MAC (EtM)
  - Encrypt-and-MAC (E-and-M)
  - MAC-then-Encrypt (MtE)

JS?
See also: @[https://jwt.io/]
- online JWT debugger to decode, verify and generate JWT,
  detailed list of libraries (Java, Python, C#, Rust,...)
  and other useful info

ºJWT online Debuggerº
- decode, verify, and generate JWTs.
@[https://jwt.io/#debugger]


JSON Web Token (JWT)
@[https://tools.ietf.org/html/rfc7519]
- URL-safe means of representing claims to be transferred between
  two parties.
  - Ussually encoded as:
    - payload of a JSON Web Signature (JWS) structure
    - plaintext of a JSON Web Encryption (JWE) structure.

JWTs can be signed with:
- symetric shared secrets (HMAC)
- asymetrict key pairs RSA/ECDSA.
(opt): JWTs can also be encrypted to provide secrecy between parties.

OºJWT structureº (JWS structure)
  xxxxx.yyyyy.zzzzz ← Base64URL encoded
  ^     ^     ^
  │  ┌──┘     │     ↖
  │  │  ┌─────┘      ☞ format more compact when compared to
  │  │  │              XML-based standards such as SAML.
  │  │ ºSIGNATUREº
  │  │ Base64URL (
  │  │   Sign (shared secret or private key,
  │  │         Base64URL encoded HEADER,
  │  │         Base64URL encoded PAYLOAD)
  │  │ )
  │  │ (Using signature algorithm of HEADER)
  │  │
  │  │
  │ ºPAYLOADº
  │  - claims about an entity + additional data.
  │
  │  - types of claims:
  │    -ºregistered : non mandatory but recommended for interoperability:
  │      º"iss"º(issuer)            º"sub"º(subject)
  │      º"exp"º(expiration time)   º"aud"º(audience)
  │      ...
  │    -ºpublicº    : Defined at will. To avoid collisions they should be defined
  │                   in the IANA JSON Web Token Registry or be defined as a URI
  │                   that contains a collision resistant namespace.
  │
  │    -ºprivateº   : custom claims between parties
  │
 ºHEADERº
  typically consists of:
  {
    "alg": "HS256", ← signing algorithm used (HMAC SHA256, RSA, ECDSA...)
    "typ": "JWT"    ← type of tokern (JWT)
  }

ºJWT common ussage patterns:º
- user agent should send the JWT in the HTTP Authorization header
  using the Bearer schema like:
  Authorization: Bearer 
  (ºStateless authorizationº)

 º☞ By sending in the Authorization header, Cross-Origin Resource Sharingº
 º  (CORS) won't be an issue as it doesn't use cookies.º

- A typicalºOpenID Connect compliant web applicationºwill go through the
 º/oauth/authorizeºendpoint using the authorization code flow.
  When the authorization is granted, the authorization server returns an
  access token back to the  application.

- no secret information must be placed into the PAYLOAD unless the JWT is
  encrypted.

- Don't store JWT inside localStorage since it's accessible by any script
  inside the page: an XSS attack can let an external attacker get access
  to the token.
- Don’t store JWT in local or session storage.
  If third-party scripts in the page  get compromised,
  they can access all your users' tokens.
- Stored JWT inside an httpOnly cookie, that’s only sent in
  HTTP requests to the server and it's never accessible
  (both for reading or writing) from JS running in the browser.

- Don't use JWT as Sessions since it's error prone.

Since JWT are signed, the receiver can be sure the client is really who it
thinks it is.


ºCOMPARATIVEº
- Signing XML with XML Digital Signature is very complex and error prone
  when compared to the simplicity of signing JSON.



JSON Web Signature (JWS)
@[https://tools.ietf.org/html/rfc7515]
   JSON Web Signature (JWS) represents content secured with digital
   signatures or Message Authentication Codes (MACs) using JSON-based
   data structures.  Cryptographic algorithms and identifiers for use
   with this specification are described in the separate JSON Web
   Algorithms (JWA) specification and an IANA registry defined by that
   specification.  Related encryption capabilities are described in the
   separate JSON Web Encryption (JWE) specification.

JSON Web Encryption (JWE)
@[https://tools.ietf.org/html/rfc7516]
   JSON Web Encryption (JWE) represents encrypted content using
   JSON-based data structures.  Cryptographic algorithms and identifiers
   for use with this specification are described in the separate JSON
   Web Algorithms (JWA) specification and IANA registries defined by
   that specification.  Related digital signature and Message
   Authentication Code (MAC) capabilities are described in the separate
   JSON Web Signature (JWS) specification.

JSON Web Key (JWK)
@[https://tools.ietf.org/html/rfc7517]
   A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data
   structure that represents a cryptographic key.  This specification
   also defines a JWK Set JSON data structure that represents a set of
   JWKs.  Cryptographic algorithms and identifiers for use with this
   specification are described in the separate JSON Web Algorithms (JWA)
   specification and IANA registries established by that specification.

JSON Web Algorithms (JWA)
@[https://tools.ietf.org/html/rfc7518]
   This specification registers cryptographic algorithms and identifiers
   to be used with the JSON Web Signature (JWS), JSON Web Encryption
   (JWE), and JSON Web Key (JWK) specifications.  It defines several
   IANA registries for these identifiers.

Implementations
- @[https://www.npmjs.com/package/node-jose]
  JS implementation of the JSON Object Signing and Encryption (JOSE)
  for current web browsers and node.js-based servers. This library implements
  (wherever possible) all algorithms, formats, and options in JWS, JWE, JWK, and
  JWA and uses native cryptographic support (WebCrypto API or node.js' "crypto"
  module) where feasible.
  Ex ussage:
  // Create Self Signed JSON token
  const ºprivKey01º= jose.JWK.asKey(
      "-----BEGIN PRIVATE KEY-----\n" +
      ...
      "-----END RSA PRIVATE KEY-----");
  const payload = { iss:"service1", aud:"service2" };
  constOºJWT01º=ºjose.JWT.signº(payload,ºprivKey01º, { expiresIn: "1 hours" });

OAuth
@[https://tools.ietf.org/html/rfc6749]
@[https://alexbilbie.com/guide-to-oauth-2-grants/]

ºUse casesº
- application that can read user data from another application
- application that enables other applications to access its user data

ºOAuth entitiesº
- Resource: (the User)  entity capable of granting access to a
  owner     protected resource.
            When the resource owner is a person, it
            is referred to as an end-user.
- Resource: ("API"server) server hosting the protected
  Server    resources, accepting and responding to
            protected resource token-attached-requests
- Client  : An application making protected resource requests
            on behalf of the resource owner and with its
            authorization. Client ca be a web app,
            server app, mobile app,...
- Authorization: Act of issuing access tokens to the client
                 after successfully authenticating server the
                 resource owner and obtaining authorization.
- access  : represents a permission granted to a client to
  token     access some protected resources.
- Scope   : ("permission") limit an application's access to a
            user's account. An App will request 1+ scopes.
            Scopes will next presented to owner (popup,...),
            finally issued access-tokens  will be limited
            to granted scopes.
            No particular scopes ared defined in
            OAuth spec(highly dependent on 
            service's internal Architecture)
            Note: Auth.Ser. can limit further the set 
                  of scopes (permission) granted to App
          @[tools.ietf.org/html/rfc6479#section-3.3]

ºINITIAL (only-once) PRESETUP:º
  Register server app to OAuth2 Service provider.
  Write down Gº'client.id' and 'client.secret'ºreturned from Service provider
  (Keycloak, Cloud Control Panel, Facebook,  ...).
   App Dev → OAuth Server : Register OAuth client
   App Dev ← OAuth Server : Gºclient.idº
                            Gºclient.secretº
   App Dev ← App Dev      : write in safe place

ºOAuth GRANTS TYPESº
┌───────────────────────────────────────────────────┐┌──────────────────────────────────────┐┌──────────────────────────────────┐
│ºRESOURCE OWNER CREDENTIALS GRANT (section 4.3)º   ││ºclient credentials grant (sect.4.4)º ││ºrefresh token grant (section1.5)º│
│  - "great user experience" for trusted first party││  - simplest oauth 2.0 grants         ││client → auth.Ser: post           │
│     clients (web and native device applications)  ││  - suitable for machine-to-machi.Auth││                   grant_type     │
│                                                   ││    where a specific user's permission││                   refresh_token  │
│user   → client  : request ...                     ││   to access data is not required.    ││                 gºclient_idº     │
│user   ← client  :  ask authorization credentials  ││client → auth.Ser: post               ││                   client_secret  │
│user   → client  :  authorization credentials      ││                   grant_type         ││                   scope          │
│client → auth.ser: POST                            ││                 gºclient_idº         ││client ← auth.Ser: json           │
│                grant_type with the value password ││                   client_secret      ││                   token_type     │
│              Gºclient_idº with the the client’s ID││                   scope              ││                   expires_in     │
│                client_secret with the client’s    ││client ← auth.Ser: json               ││                 Oºaccess_tokenº  │
│                secret scope with a space-delimited││                   token_type "bearer"││                   refresh_token  │
│                list of requested scope permissions││                   expires_in         │└──────────────────────────────────┘
│                username with the user’s username  ││                 Oºaccess_tokenº      │
│                password with the user’s password  │└──────────────────────────────────────┘
│client ← auth.ser: JSON object                     │
│                   token_type "Bearer"             │
│                   expires_in                      │
│                 Oºaccess_tokenº                   │
│                 Oºrefresh_tokenº                  │
└───────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐  ┌──────────────────────────────────────────────────────────────────────┐
│ºAUTHORIZATION CODE GRANT (Section 4.1)º                 │  │ -ºIMPLICIT GRANT (SECTION 4.2)º                                      │
│                                                         │  │   "WEB BROWSER*                                                      │
│ ºSTEP 1: Authenticating user and getting Auth. code     │  │   - similar to AUTHORIZATION CODE GRANT Sec. 4.1) with               │
│ user → client: req resource                             │  │     two distinct differences:                                        │
│ user ← client: redirect to Authorization Server         │  │     - Targeting user-agent-based clients (e.g. single page web apps) │
│                --------------------------------         │  │       that can't keep a client secret because all of the application │
│            URL query parameters in redirect URL         │  │       code and storage is easily accessible.                         │
│            - response_type with the value code          │  │     - instead of the Authorization Server returning an authorization │
│          Gº- client_idº    with the client identifier   │  │       code which is exchanged for an access token, the authorization │
│            - redirect_uri  (opt) defaults to            │  │       server returns an access token.                                │
│                            pre-registered URI           │  │                                                                      │
│            - scope         a space delimited scope-list │  │ user → client: request access                                        │
│            - state         (opt, but highly recommended)│  │ client → user: redirect to Auth.Server                               │
│                            Used to avoid "mixing"       │  │                -----------------------                               │
│                            different user's session on  │  │                URL req. param:                                       │
│                            callback                     │  │                response_type     with the value token                │
│ user → auth.ser: ...?response_type=..                   │  │              Gºclient_idº        with the client identifier          │
│                     ⅋client_id=..                       │  │                redirect_uri      Optional. Def.to pre-registered one │
│                     ⅋redirect_uri=..                    │  │                scope             a space delimited list of scopes    │
│                     ⅋scope=..⅋state=...                 │  │                state             (optional but highly recommended)   │
│ auth.ser → auth.ser: validate input                     │  │ user → auth.server: ...                                              │
│ user ← auth.ser: Login                                  │  │ auth.server → auth.server: checks...                                 │
│ user → auth.ser: "Credentials" proof                    │  │ user ← auth.server: request Credentials                              │
│              (can involve form with user/pass           │  │ user → auth.server: login with "credentials" proofs                  │
│               or complex multiFactor Auth/channel/steps)│  │                     and  approve the client                          │
│ auth.ser → auth.ser: Validate "credentials" proof       │  │ user ← auth.server: redirect to client                               │
│ user ← auth.ser: Redirect to reditect_uri               │  │                     -----------------------                          │
│                     ------------------------            │  │                     token_type    "Bearer"                           │
│                     URL reditect parameters:            │  │                     expires_in    TTL                                │
│             Oº- code  with the authorization codeº      │  │                   Oºaccess_tokenº the access token itself            │
│               - state (param.sent in original request)  │  │                     state         must be compared in client         │
│ user → client  :URL?code=....⅋state=...                 │  │                                   with the original value            │
│ client → client: check Init State = Receive state       │  │                     ^^^^^^^^^^^^                                     │
│                  (Avoid mixing different user sessions) │  │                     this grant does NOT return                       │
│                  Associate code to user's session       │  │                     refresh token because the browser                │
│                                                         │  │                     has no means of keeping it private               │
│ ºSTEP 2: Using code to get Access Tokenº                │  └──────────────────────────────────────────────────────────────────────┘
│ client → auth.ser: POST                                 │
│                    ────                                 │
│                    grant_type with the value of         │
│                    authorization_code                   │
│                  Gºclient_idº with the client identifier│
│                  Gºclient_secretº with the client secret│
│                    redirect_uri (original redirect URI) │
│                  Oºcodeº                                │
│ client ← auth.ser: JSON object                          │
│                token_type     usually "Bearer"          │
│                expires_in     access token TTL(Integer) │
│              Oºaccess_token   the access token itselfº  │
│                refresh_token  used refresh on expiration│
│                               time                      │
└─────────────────────────────────────────────────────────┘
See also:
-@[https://oauth.net/2/]

OpenID

OpenID
@[https://stackoverflow.com/questions/1087031/whats-the-difference-between-openid-and-oauth]
@[https://security.stackexchange.com/questions/44611/difference-between-oauth-openid-and-openid-connect-in-very-simple-term/130411#130411]
@[https://en.wikipedia.org/wiki/OpenID#OpenID_vs._pseudo-authentication_using_OAuth]
    """
    OpenID is about verifying a person's identity.
    OAuth is about accessing a person's stuff.
    OpenID Connect does both.
    """
OpenID Connect (2014) combines the features of OpenID 2.0, OpenID Attribute Exchange 1.0, and OAuth 2.0 in a single protocol.

Dex
@[https://github.com/dexidp/dex]
Dex is an identity service that uses OpenID Connect
to drive authentication for other apps.
Dex acts as a portal to other identity providers through
"connectors." This lets dex defer authentication to
LDAP servers, SAML providers, or established identity
providers like GitHub, Google, and Active Directory.

 Clients write their authentication logic once to talk
to Dex, then Dex handles the protocols for a given backend.

OpenID vs OAuth2 vs SAML
REF:
@[https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/]

- single sign-on (SSO) allows a user to enter sign once
  and "enter" multiple applications or web-sites.
  This means that some sort of "authentication token"
  must be provided to the user on first sign for later
  reuse.

- developers of the SSO applications don't have to
  store or request for passwords. Instead, they can
 ºaccept proof of identity or authorizationº
 ºfrom a trusted sourceº

- OpenID, OAuth2 and SAML are different security protocols
  for single sign-on

  the relying party.
ºOpenIDº
- open standard for authentication
- As of March 2016, there are over a billion
  OpenID-enabled accounts on the internet.
- Google, WordPress, Yahoo, PayPal use OpenId
  to authenticate users.

OpenID FLOW:
user → id_provider01: request OpenID account
user ← id_provider01: OpenID account
                      ^^^^^^^^^^^^^^
                      technically it's a URL
                      (e.g. alice2016.myIDprovider.org)

user → web_site login_screen: Select "sign with id_provider01"
       (relying party)
web_site login_screen → id_provider01: request association handle
web_site login_screen ← id_provider01: association handle
user ← web_site login_screen: redirect to id_provider01 login page
user → id_provider01: enter OpenID account + credentials (pass,...)
user ← id_provider01: auth.token + url_redirect o web_site
                      ^^^^^^^^^^
                      signed claim statying that id_provider01
                      believes user is actually user
user → web_site url : auth.token
web_site url → web_site url : Check auth.token is signed by trusted
                              id_provider01
web_site url → web_site url : Create session for user
user ←→ web_site url : --- app session ---

- 2014: Latest version (OpenID Connect) combines:
  - OpenID authentication  (user is who he claims to be)
  - OAuth2 authorization   (user is authorized a set of actions)

ºOAuth2º
- Confusingly, OAuth2 is also the basis for OpenID Connect -2014-)
- Confusingly, authorization is also considered some time a form
 of pseudo-authentication and OAuth2 is claimed to be an
 authentication standard. (An authorization signed token is a
 claim that the user is believed to be himself for the act of
 executing an action or accesing some resource).

- open standard for authorization.
- OAuth2 provides secure delegated access:
  - application clients will use temporal tokens issued by
    the identity-provider to the user to access resources
    on another resource-server on behalf of the user.

ºSAMLº
- 2001: oldest standard of the three
- 2005: latest update.
- stands for Security Assertion Markup Language.
- provides authentication + authorization.
- SAML defines:
  - principal (end user).
  - service provider (application web site)
  - identity provider:  server holding principal's ids + credentials.

user           → ser_rovider01: request service (action on a webapp)
ser_provider01 → id_provider  : XML message
                                -----------
                                required info
                                who_is_asking (ser_provider01)
                                response_url
id_provider    → response_url : SAML signed response assertion
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                               (similar to a token in OpenID/OAuth2).
                                The assertion can contain statements
                                about authentication, authorization,
                                and/or attributes (emails, phones,...).

SAML 2.0 defines:
- assertions:
- protocols : assertion requests and responses)
- bindings  : how requests/responses happen between the service provider and identity provider
              using communication methods like HTTP POST
- profile   : allowed combinations of (assertions, protocols, bindings)
              for various use cases, like SSO.

                    OAuth2             OpenId              SAML

Token format        JSON or SAML2      JSON                XML
(assertion)

Authorization?      Yes                No                  Yes

Authentication?     Pseudo-auth        Yes                 Yes

Year created        2005               2006                2001

Current version     OAuth2             OpenID              SAML 2.0
                                       Connect

Transport           HTTP               HTTP                - HTTP Redirect
                                       GET/POST              (GET) binding
                                                           - SAML SOAP
                                                             binding
                                                           - HTTP POST
                                                             binding
                                                           - "others"


SECURITY RISKS      Phishing[1]        Phishing[1]         XML Signature
                                                           Wrapping to
                                                           impersonate
                                                           any user



Best suited for     - API              - consumer apps     enterprise
                      authorization      Single sign-on    Single sign-on
                                         delegating SSO
                                         to Google,...

TLS protocol

External Links
- Wikipedia
- Mozilla SSL config generator
- Mozilla Server Side TLS
- SSL Server Test

X.509 Format
@[https://en.wikipedia.org/wiki/X.509]

(ITU_T standard)
Can be seen as an accepted (== signed by CA) public-key
plus metadata about such public-key.
The CA signature claims that the public-key and metadata
are valid for the CA.

The current content will be:
- ºpublic key certificatesº
- ºidentityº: hostname + organization/individual
- ºcertificate revocation listsº: certificates are no longer
  valid,
- ºcertification path validation algorithmº allowing for
  certificates to be signed by intermediate CA certificates, which are in
  turn signed by other certificates, eventually reaching a trust anchor.
- Used amongst others by Internet protocols like TLS/SSL
- X.509 v3:
  Version#
  Serial Number
  Signature algorithm
  Issuer name
  Validity period
  Subject name
  Subject PK Info
  Issuer ID#
  Subject ID#
  Extensions
  ──────────────────
  CA Signature
- "Extended attributes" (Used by different services)
ºView x509 contents:º
$ openssl x509 -text -in myCert.pem

openSSL
│ºExternal Refsº
│@[https://www.openssl.org/docs/manmaster/man1/]
│@[https://www.ietf.org/rfc/rfc5280.txt] X.509 PKI
│- The Most Dangerous Code in the World: Validating SSL Certs ...:
│@[https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf]


│ºCommon optsº
│-nodes: flag: ºDO NOTº pass-phrase-encrypt Pub.Key
│-noout: prevents output of encoded version of request
│-text : Show human readable output (vs hex formated binary))


│ºGlobal Flowº                             │ºuseful ENV.VAR (DOMAIN/SUBJ)º
│admin→admin: Create Private Key           │$ export DOMAIN="mydomain.com"
│admin→admin: Create CSR                   │$ export SUBJ=""
│alt                                       │$ export SUBJ="${SUBJ}/C=ES"
│  admin→admin: Create self-certificate    │$ export SUBJ="${SUBJ}/ST=Aragon"
│else:                                     │$ export SUBJ="${SUBJ}/L=Zaragoza"
│  admin→CA   : CSR                        │$ export SUBJ="${SUBJ}/O=MyOrganization"
│  CA→CA      : Create certificate         │$ export SUBJ="${SUBJ}/CN=${DOMAIN}"
│  CA→amdin   : certificate                │$ export NUM_OF_DAYS="999"
│
│
│Cert.Sign.Requestº                        │ºCreating a CSR*
│ºCSRº                                     │$ openssl req \
│CSR :=                                    │  º-newº\
│    PUBLIC KEY                            │   -nodes
│  + Distinguised Name (DN) :=             │   -newkey rsa:2048 \
│       + Common Name (CN)                 │   -keyout ${DOMAIN}.key \
│         (SHOULD be the exact             │   -out ${DOMAIN}.csr -subj "${SUBJ}"
│          Fully Qualified Dom Name(FQDN)  │
│          of the host)                    │(replace -newkey rsa:.... -keyout... by
│       + "additional info                 │            -key ${DOMAIN}.key to use
│          about organization"             │            already existing private key)



│ºManaging Private Keysº                   │ºdump x509 infoº
│ºCREATE A PRIVATE KEY:º                   │$ openssl x509 -text -in myCert.pem
│$ openssl \
│    genrsa -des3 \
│    -out ${DOMAIN}.key 2048
│(Enter password when prompted)
│
│ºVERIFY PRIVATE KEY:º
│$ openssl rsaº-checkº-in ${DOMAIN}.key
│
│ºVerify private key matches certificate and CSRº
│ (If the output of each of the next command is identical there is an
│  extremely high probability that the private key, certificate,
│  and CSR are related)
│  $ openssl rsa  -noout -modulus -in ${DOMAIN}.key | openssl md5
│  $ openssl x509 -noout -modulus -in ${DOMAIN}.crt | openssl md5
│  $ openssl req  -noout -modulus -in ${DOMAIN}.csr | openssl md5
│
│ºEncrypt/Decrypt private keyº
│$ openssl rsa -des3 -in unencrypted.key -out encrypted.key
│$ openssl rsa       -in encrypted.key   -out decrypted.key


│ºSelf-Signed-Certº
│ºworking on Chrome/Java/...º
│REF:
│- chrome deprecates subject cn matching]
│@[https://textslashplain.com/2017/03/10/chrome-deprecates-subject-cn-matching/]
│- Fixing Fixing Chrome 58+ [missing_subjectAltName] with openssl&S.S.certs
│@[https://alexanderzeitler.com/articles/Fixing-Chrome-missing_subjectAltName-selfsigned-cert-openssl/]
│- getting-chrome-to-accept-self-signed-localhost-certificate
│@[https://stackoverflow.com/questions/7580508/getting-chrome-to-accept-self-signed-localhost-certificate/43666288#43666288]
│ºcreate_root_cert_and_key.shº
│ |#!/usr/bin/env bash
│ |openssl genrsa -out rootCA.key 2048
│ |openssl req -x509 -nodes \
│ |    -days $NUM_OF_DAYS \
│ |    -key rootCA.key -sha256 \
│ |    -out rootCA.pem
│ |    -new
│      ^^^^
│      replace with -in $DOMAIN.csr to reuse crt

│ºcreate_certificate_for_domain.shº
│ |#!/usr/bin/env bash
│ |
│ |if [ -z "$1" ]; then
│ |  echo "Ussage: $0 myDomain.com"
│ |  echo "           ^^^^^^^^^^^^"
│ |  echo "    # alt1     wildcard"
│ |  echo "        $0 www.myDomain.com"
│ |  echo "           ^^^^^^^^^^^^^^^^"
│ |  echo "    # alt2 non-wildcard"
│ |  exit 1;
│ |fi
│ |if [ ! -f rootCA.pem ]; then echo 'no rootCA.pem detected. Please, run create_root_cert_and_key.sh first, and try again!' ; exit 1; fi
│ |if [ ! -f v3.ext     ]; then echo 'Please download the "v3.ext" file and try again!' ;  exit; fi
│ |
│ |if [ -f $DOMAIN.key ]; then KEY_OPT="-key" else KEY_OPT="-keyout" fi #  ← Create new Priv.Key || reuse existing one
│ |
│ |cat ˂˂ EOF ˃ /tmp/__v3.ext
│ |authorityKeyIdentifier=keyid,issuer
│ |basicConstraints=CA:FALSE
│ |keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
│ |subjectAltName = @alt_names
│ |
│ |[alt_names]
│ |DNS.1 = $COMMON_NAME
│ |EOF
│ |
│ |openssl req -new -newkey rsa:2048 \
│ |   -sha256 -nodes $KEY_OPT $DOMAIN.key \
│ |   -subj "$SUBJECT" -out $DOMAIN.csr
│ |openssl x509 -req -in $DOMAIN.csr \
│ |   -CA rootCA.pem -CAkey rootCA.key \
│ |   -CAcreateserial -out $DOMAIN.crt \
│ |   -days $NUM_OF_DAYS -sha256 \
│ |   -extfile /tmp/__v3.ext
│
│ºUssage:º
│$ ./create_root_cert_and_key.sh        # ← STEP 01: create root Auth cert
│
│$ ./create_certificate_for_domain.sh \ # ← STEP 02
│   mysite.com                          #   Alt 1
│   www.mysite.com www.mysite.com       #   Alt 2
│
│Note: You will also new to import the new cert. authority.
│For example on Mac:
│    Open Keychain Access
│    Choose "System" in the "Keychains" list
│    Choose "Certificates" in the "Category" list
│    Choose "File | Import Items..."
│    Browse to the file created above, "rootCA.pem", select it, and click "Open"


│ºConverting Formatsº
│- X.509 DER ENCODING: Binary       encoding for X.509v3 certificates
│- X.509 PEM ENCODING: Base64-ASCII encoding for X.509v3 certificates, prefixed with a "—– BEGIN ..." line
│
│- NOTE common X.509 file extensions include:
│  - .CRT: certificates encoded as binary der or as ascii pem.
│  - .CER: certificates . Mostly similar to .CRT, recognized
│          by some Microsoft products (IE, MS cryptoAPI commands, ...)
│  - .KEY: used for private PKCS#8 keys (and its corresponding public key)
│          encoded as binary DER or as ASCII PEM.
│
│- PKCS#7  Standard: Cryptographic Message Syntax used to sign and/or encrypt messages under PKI
│                    - ASCII files, also known as P7B,
│                      which can contain (non-secret) certificates
│                      and CA certificates.
│
│- PKCS#12 Standard: file format commonly used for (private)keystores, protected with a password-based
│                    symmetric key. Used by:
│                    - Java key store
│                    - client auth. certs in Firefox, Apache Tomcat
│                    - Files are also known as PFX files
│ (OpenSSL defaults to X.509 PEM format
│
│PER ←→ DER
│$ openssl x509 -inform pem -in ${DOMAIN}.crt -outform der -out ${DOMAIN}.der # PEM   → DER
│$ openssl x509 -inform der -in ${DOMAIN}.der -outform pem -out ${DOMAIN}.crt # DER   → PEM
│
│# PEM   → PKCS7
│$ openssl crl2pkcs7 -nocrl -certfile ${DOMAIN}.crt -certfile ca-chain.crt -out ${DOMAIN}.p7b
│# PKCS7 → PEM
│$ openssl pkcs7 -in ${DOMAIN}.p7b -print_certs -out ${DOMAIN}.crt
│
│# PEM → PKCS12
│$ openssl pkcs12 -inkey ${DOMAIN}.key \
│   -in ${DOMAIN}.crt -export -out ${DOMAIN}.pfx
│# PKCS12 → PEM
│$ openssl pkcs12 -in ${DOMAIN}.pfx -nodes -out ${DOMAIN}.combined.crt
│# x509 → PEM
│$ openssl x509 -in ${DOMAIN}.cer -outform PEM -out ${DOMAIN}.pem


│ºFingerprintsº
│- Fingerprints are short sequences of bytes used to identify a longer public key,
│  applying a cryptographic hash function to the public key
│- Are used as "ids" to the longer public keys
│- To generate a fingerprint from a TLS certificate, run:
│$ openssl x509 -in ${DOMAIN}.crt -noout -fingerprint -sha256
│(output will be similar to
│ fa:23:a4:48:............:56


│ºfetch first-in-chain web cert.,º              │ºlist openssl version/buildº
│ºthen add to Java.KeyStore:º                   │$ openssl version -a
│$ openssl s_client \
│   -connect www.mywebsite.com:443 \
│   -showcerts ˂/dev/null 2˃/dev/null | \       │ºView and Verify CSRº
│  openssl x509 \                               │$ openssl req \
│    -outform PEM ˃ infura-morden.pem           │  -text  \  # "view"
│$ ($JAVA_HOME/Contents/Home/jre/bin/)keytool \ │  -verify \ # "verify"
│    -import -noprompt -trustcacerts \          │  -noout \
│    -alias www.mywebsite.com -f                │-in ${DOMAIN}.csr


│*Verify that cert. was
│ signed by a given CA:
│$ openssl verify -verbose
│    \ -CAFile ca.crt ${DOMAIN}.crt



│ºCertificate revocation listsº
│RºWARN:º Some companies/applications have deprecated CRLs and are
│         instead using the ºOnline Certificate Status Protocol (OCSP)º
│
│- A CRL provides a list of certificates that have been revoked.other TLS projects
│
│STEP 1: Prepare CLR config file
│$ vim .../intermediate/openssl.cnf
│ [ CA_default ]
│ ...
│ default_crl_days = 30 ← STEP 2 must be periodically executed
│ ...                     this delay
│ [ server_cert ]
│ # ... snipped ...
│*crlDistributionPoints = URI:http://example.com/intermediate.c
│ ^^^^^^^^^^^^^^^^^^^^^
│ See man page for more crl options
│
│STEP 2: Create the CLR
│(Repeat perioadically according to default_crl_days in config)
│$ cd ~/ca
│$ openssl ca \
│  -config intermediate/openssl.cnf \
│ º-gencrlº \
│  -out intermediate/crl/intermediate.crl.pem
│
│STEP 3: Verify output of STEP 2:
│$ openssl crl \
│  -in intermediate/crl/intermediate.crl.pem \
│  -noout -text
│→ ... No Revoked Certificates
│ (No certificates have been revoked yet)
│
│STEP 4: make intermediate.crl.pem accessible through
│        the HTTP URL  indicated in STEP 1
│
│NOTE: For servers authenticating clients through
│      X.509 certs, copy the generated crl file
│      to a path indicated by the server config
│      ('SSLCARevocationPath' in Apache HTTP,
│      'crl-verify' in OpenVPN,...)
│
│REVOKE A CERTIFICATE:
│$ cd ~/ca
│$ openssl ca -config intermediate/openssl.cnf \
│ º-revokeº \
│  intermediate/certs/bob@example.com.cert.pem
│
│For a given X.509 certificate the CRL distribution
│points are visible in the certificate X509v3 details.
│
│# openssl x509 -in ${DOMAIN}.cert.pem -noout -text
│→ ...
│→   X509v3 CRL Distribution Points:
│→
│→       Full Name:
│→         URI:http://domain1.com/intermediate.crl.pem
│→ ...

Related projects:
@[https://jamielinux.com/docs/openssl-certificate-authority/index.html]

Certs Transparency
@[https://www.certificate-transparency.org/]
(See also Trillian
- G.C.T. project fixes several structural flaws in the SSL certificate system
matching- open framework for monitoring and auditing SSL certificates in nearly real time.
  detecting SSL certificates that have been mistakenly issued by a certificate authority
  or maliciously acquired from an otherwise unimpeachable certificate authority.
  It also makes it possible to identify certificate authorities that have gone rogue
rl.pem*  and are maliciously issuing certificates.
-ºCertificate LOGSº:simple network services that maintain cryptographically
assured, publicly auditable, append-only records of certificates. Anyone can
submit certificates to a log, although certificate authorities will likely be
the foremost submitters
-ºMonitorsº are publicly run servers that periodically contact all of the log
servers and watch for suspicious certificates. For example, monitors can tell
if an illegitimate or unauthorized certificate has been issued for a domain,
and they can watch for certificates that have unusual certificate extensions
or strange permissions, such as certificates that have CA capabilities.

-ºAuditorsº: lightweight components performing two functions:
- verify that logs are behaving correctly and are cryptographically
consistent. If a log is not behaving properly, then the log will need to explain
itself or risk being shut down.
- verify that a particular certificate appears in a log. This is a particularly
important auditing function because the Certificate Transparency framework
requires that all SSL certificates be registered in a log. If a certificate has
not been registered in a log, it’s a sign that the certificate is suspect, and
TLS clients may refuse to connect to sites that have suspect certificates.

Cert.Authorities (CAs)

Let's Encrypt
@[https://letsencrypt.org/]
- free, automated, and open Certificate Authority.

@[https://certbot.eff.org/about/]
- Certbot is a free, open source software tool for automatically using Let’s
  Encrypt certificates on manually-administrated websites to enable HTTPS.

- Certbot might be right for you if you:
  - have comfort with the command line
  - have an HTTP website that’s already online
  - and administer your website via a dedicated/cloud server
  - which you can access via SSH
  - have the ability to sudo

- Certbot is part of EFF’s larger effort to encrypt the entire Internet.
  Websites need to use HTTPS to secure the web. Along with HTTPS Everywhere,
  Certbot aims to build a network that is more structurally private, safe, and
  protected against censorship.

cacert.org
@[http://www.cacert.org]
- Mission Statement: create a Non-Profit Certificate Authority;
                     alternative to the commercial CAs.

 make-ca
(KISS CA)
@[https://github.com/djlucas/make-ca/blob/master/make-ca]
-  Simple scripts around OpenSSL to create a local certificat authority

TLS Related

OCSP
@[https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol]

- Internet protocol used for obtaining the revocation status of an X.509 digital certificate.
- Alternative to Certificate Revocation Lists to addressg problems associated with
  using CRLs in a public key infrastructure (PKI).
- Messages are encoded in ASN.1

- Architecture is "request/response" message based.
- Supported by different web browsers

ºComparison to CRLsº
- OCSP response contains less data than a typical CRL file
- easier to parse by end client-side libraries
- OCSP discloses to the responder that """a particular
  network host used a particular certificate at a particular time"""

ºBasic PKI implementationº
participant: Alice  with certificate issued by CA Carol
participant: Bob    with certificate issued by CA Carol
Carol      : CA

Alice wishes to perform a transaction with Bob.
Alice → Bob: Alice pub.key Certificate
Bob   → Bob:(concerned that Alice's priv.key is compromised)
             creates an 'OCSP-request'
                        --------------
                        Alice_cert.serial_number
Bob   → Carol: OCSP-request
Carol → Carol: reads certificate serial number.
               Search if serial number is in revocation ddbb
Carol → Bob  : Signed OCSP-response with
               'good'|'revoked'|'unknown'|'error code'
               key signing OCSP-response must be the
               original key signing the cert. originally
               or another cert. issued by the original CA
               that is marked with a certain extension to
               flag it as OCSP signing authority.
rigi


Bob   → Bob  : verifies Carol's signed response.
               (it's supposed that Bob has stored Carol's
                pub.key sometime before this transaction)

Bob   → Alice: ...

ºProtocol detailsº
- OCSP request format supports additional extensions.
- OCSP can be vulnerable to replay attacks,[5] where a signed,
  'good' response is captured by a malicious intermediary and
  replayed to the client at a later date after the subject
  certificate may have been revoked.  A nonce can be included
  to avoid it.
  - Because of high load, most OCSP responders do not use the
    nonce extension to create a different response for each
    request, instead using presigned responses with a validity
    period of multiple days.
   ºThus, the replay attack is a major threat to validation systemsº

- OCSP can support more than one level of CA chaining/forwarding
  initial OCSP-requests to by delegated path validation (DPV) servers.

(See Criticisms in original wikipedia article)

Supported by
Internet Explorer, Mozilla Firefox 3+, Safari-macOS.
RºGoogle Chrome disabled OCSP checks by default in 2012º
Rºciting latency and privacy issues and instead uses theirº
Rºown update mechanism to retrieved revoked certificatesº

XML Signature
@[https://en.wikipedia.org/wiki/XML_Signature]

- also called XMLDSig, XML-DSig, XML-Sig
- XML syntax for digital signatures
- W3C recommendation
- it has much in common with PKCS#7 but is more extensible
- used by various XML related technologies like SOAP or SAML

- typically used toto sign XML documents,
 ºbut anything that is accessible via a URL can be signedº

- An XML signature used to sign a resource outside its containing
  XML document is called a detached signature;
- If used to sign some part of its containing document, it is
  called an enveloped signature;
- if it contains the signed data within itself it is called an
  enveloping signature.

- Rºcreation of XML Signatures is substantially more complexº
  Rºthan the creation of an ordinary digital signature becauseº
  Rºa given XML Document may have more than one legal serializedº
  Rºrepresentationº
  - XML canonicalization transform is employed to alleviated some of
    those problems

(See detailed description in Wikipedia source)

Best Patterns

Common protocol issues
- ciphertext that aren't secured with a MAC
- message that don't include a time-stamp or counter
- protocols that don't use PK for authenticity
- Reuse of Nonces of IVs
- ... many more

###########
# Dont's!!#
###########
- Don't Implement your own algorithms
- Don't Use hard-coded keys, use a Vault service.
  Don't use a Vault when you can use wallet. (that will use an
  internal vault and never expose secrets outside)
- Never use ECB mode. Prefer CBC, better yet CTR or
  GCM@[https://en.wikipedia.org/wiki/Galois/Counter_Mode]
- Don't use small public key sizes. At least 2048
- Elliptic curve preferable: p-256 or X25519
- Don't use the same private key for encrypting and signing
- Don't reuse the same nonce twice -it will no be a nonce-

kerberos+ldap "=" AD

Kerberos protocol
@[https://en.wikipedia.org/wiki/Kerberos_(protocol)]
@[https://web.mit.edu/Kerberos/]
- computer-network protocol designed to
 ºprovide strong client/server mutual authenticationº

- ºbuilt on symmetric key cryptographyº and
  ºmay (optionally) use public-key cryptographyº
  ºduring certain phases of authenticationº
- ºrequires a trusted third partyº
- ºworks on the basis of ticketsº
- allow nodes communicating over a non-secure network
  to prove their identity to one another in a secure manner,
  protecting against eavesdropping and replay attacks.

ºHistory and developmentº
- 19?? MIT 1st Kerberos version
  based on the earlier Needham–Schroeder symmetric key protocol.
- Versions 1-3 were only MIT internals.

- Late 1980s: version 4 (by Steve Miller and Clifford Neuman)

- 1993: Version 5, becomes also RFC 1510

- 2000: Default authentication method in Windows 2000
        - RFC 3244 documents Microsoft additions to the standard
          suite of protocols:
        "Microsoft Windows 2000 Ker. Change and Set Password Proto."
        RFC 4757 documents Microsoft's use of the RC4 cipher.
        Kerberos is used as preferred authentication method:
       ºIn general, joining a client to a Windows domain means   º
       ºenabling Kerberos as default protocol for authenticationsº
       ºfrom that client to services in the Windows domain and   º
       ºall domains with trust relationships to that domain.     º
       (fallback to NTLM ifeither client or server are not joined to a domain*


- 2005: RFC 4120 makes (1993) RFC 1510 obsolet. Updates by IETF included:
  - Encryption and Checksum Specifications (RFC 3961)
  - AES (RFC 3962)
  - new edition of the Kerberos V5 spec
    "The Kerberos Network Authentication Service (V5)" (RFC 4120).
  - new edition of
    "The Kerberos V5 Generic Security Service API (GSS-API) Mechanism: Version 2." (RFC 4121).

- 2???: MIT implementation freely available (BSD license)

- 2007: MIT formed the Kerberos Consortium to foster continued development.
        Founding sponsors include Oracle, Apple, Google, Microsoft, Centrify Corporation, TeamF1,
        Royal Institute of Technology in Sweden, Stanford University, MIT, CyberSafe.

ºProtocol Descriptionº

participant client
participant Service Server          as SS
participant Auth.Server             as AS
participant Key.Distribution.Center as KDC
participant Ticket.Gathering.System as TGS
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            Ussually KDC and TGS share the
            same host

PRE-SETUP: Register SPN at TGS with a Service Principal Name (SPN01)
SS → TGS: Register SPN01

LOGIN-FASE: Gathering new TGT (ticket-granting ticket)
  client →  client: username01, password01
  client →  client: alt 1: key01 = chiper(secret_key, password01)
                    alt 2: key01 = hash  (password01)
  client →  AS: username01
  AS     → KDC: username01
  KDC    → KDC: issues new TGT01
                           -----
                           - time-stamp
                           - expiration-time

  KDC    → KDC: encryptedTGT01 = sym_cipher(secret_key, TGT01)
  KDC    → client: encryptedTGT01 (usually at user logon)


STEP 2: Communicating with other nodes ("principal")
  client → TGS: TGT01 + SPN01
                        ^^^^^
                        SPN01 registered in PRE-SETUP.
  TGS    → TGS: verify TGT01
                verify client is allowed access to TG01
  TGS    → client: Session Ticket st01 + Session Keys
  client → SS: session ticket st01 + sess.keys + service request

ºDrawbacks and limitationsº
- Kerberos requires user accounts, user clients
  and the services on the server to all have a
  trusted relationship to the Kerberos token server
  All must be in the same Kerberos domain or in domains
  that have a trust relationship between each other.
  - creating staged environments (e.g. separate domains for
    test, pre-production, production) is difficult.


ºKerberos delegationº
- Kerberos delegation is used in multi-tier application/service situations:
-  A common scenario would be a web server application making calls to
   a database running on another server.
   -  The first tier is the user who browses to the web site’s URL.
   -  The second tier is the web site.
   -  The third or data tier would be the database.
  ºDelegation allows the database to know who is actually accessing its dataº

  Non-Kerberos Security Setup:
    webserver_admin → database1_admin : request database  access for "WebServerAcct"
    database1_admin → database1_admin : grant "sufficient" access to "Database1Acct"
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    webapp developers and/or admins determine who can access the web application
    and by extension the data in the back end.
    Rº(it may be unacceptable to the database admins as they cannot control whoº
    Rº ultimately has access to the data)                                      º

  Kerberos delegation Setup:
    - grant "WebServerAcct" permission to delegate to the "Database1Acct".
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      When a user accesses the web site they authenticate with Windows Integrated Authentication:
      user → webserver: request + user-kerberos-ticket1
                                  ^^^^^^^^^^^^^^^^^^^^^
                                  contains a list of the user's
                                  AD group memberships.

      webserver → webserver: check that user-kerberos-ticket1 is in Database group
      webserver → AD controller: (delegation configure)
                                 request a Kerberos ticket to the database
                                 impersonating the user rather than "WebServerAcct"
      ...
      webserver → Database1: request + user-kerberos-ticket2
      Database1 → Database1: check that user-kerberos-ticket1 is allowed

LDAP
@[https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol]

- application protocol for accessing and maintaining distributed
  directory information services over an Internet Protocol (IP) network.

- Directory services roles:
  - share information about users and services throughout the network,
    like mails, phones, user/passwords, ...

ºHistoryº
- 1980s: Telco companies develop the concept of directory services
         culminating in the comprehensive X.500 specification
         by the International Telecommunication Union (ITU) in the 1980s.

- 1993 : First version created as a subset of X.500 for TCP/IP
         While the X.500 was "heavy" in network bandwith, LDAP was
         "light", better suited for TCP/IP at that time.

- 1997: LDAPv3
        - added support for extensibility
        - integrates Simple Authentication and Security Layer

- 2006: Latest version (RFC 4511)
        road map to the technical specifications is provided by [RFC4510]
        - The Protocol [RFC4511]
        - Directory Information Models [RFC4512]
        - Authentication Methods and Security Mechanisms [RFC4513]
        - Uniform Resource Locator [RFC4516]
        - ...

ºProtocol overviewº
- ASN.1 binary BER encoded (Basic Encoding Rules)

participant Directory_System_Agent (LDAP_server) as DSA
client → DSA: connect
client → DSA: operation request  ← With some exceptions, client does
client ← DSA: operation response   not need to wait for a response
              ^^^^^^^^^            before sending the next request.
                │                  Server may respond in any order.
       ┌────────┘
 operation can be:
 - StartTLS    :
 - Bind        : authenticate and specify LDAP protocol version
 - Search      : search for and/or retrieve directory entries
 - Compare     : test if a named entry contains a given attribute value
 - Add    entry:
 - Delete entry:
 - Modify entry:
 - Modify DN   : move/rename an (D)istinguished (N)ame
 - Abandon     : abort a previous request
 - Extended Op : generic operation used to define other operations
 - Unbind      : close the connection (not the inverse of Bind)

ºDirectory structureº
- (Follows X.500 1993 model)
- attribute = [ name, value+]
- attributes are defined in a schema
- entry == [parent DN, Relative DN  , [attribute1, attribute2,...] ]
                       ─────────────   ──────────  ──────────
                       att name: cn    name        name
                       att value:...   val1        val1,val2
                       └───────────┘
                        Relative
                        Distinguished
                        Name
            └───────────────────────┘
             Distinguished Name (DN)

      Example entry in LDIF format
      (LDAP Data Interchange Format)
                                           (Mentally)
   ┌─→dn: cn=John Doe,dc=example,dc=com  ← /com/example/John Doe
   │      └───────────────────────────┘    └──────────┘ └──────┘
   │        Distinguished Name (DN)         Parent DN     RDN
   │  cn: John Doe                         └───────────────────┘
   │  givenName: John                              DN
   │  sn: Doe
   │  telephoneNumber: +1 888 555 6789               ┌────  Each entry must have an objectClass
   │  telephoneNumber: +1 888 555 1232               │      attribute, containing named classes
   │  mail: john@example.com                         │      defined in the schema.
   │  manager: cn=Barbara Doe,dc=example,dc=com      │      The schema definition of the classes
   │  objectClass: inetOrgPerson                 ←───┤      of an entry defines what kind of
   │  objectClass: organizationalPerson          ←───┤      object the entry may represent
   │  objectClass: person                        ←───┤      (e.g. person, org, domain,...)
   │  objectClass: top                           ←───┘      The object class definitions also
   ├─ UUID: 3ff91489-7d7e-4cdf-884e-f04753d2e6fa            define the list of attributes that
   │                                                        - must contain values
   └─ DN may change over the lifetime of the entry          - may  contain values.
      for instance, when entries are moved within a tree.
      An UUID attribute might be provided in the set of
      the entry's operational attributes to really have
      a Unique ID associated to the entry
      - 'dn' is neither an attribute nor a part of the entry.

      Note: dc stands for (D)omain (C)omponent

- A server holds:
  - a subtree starting from a specific entry*
    For example: "dc=example,dc=com"
  - (optional) references to other servers
    an attempt to access a dn in other server will
    return a server-referral to the client.
    - (optional) some servers support chaining:
      - The server will directly contact the other
        servers on behalf of the client

-ºLDAP rarely defines any orderingº
 (sets need not be ordered)

BIND also sets the LDAP protocol version by sending a

When LDAP servers are in a replicated topology, LDAP clients should consider using the post-read control to verify updates instead of a search after an update.

ºURI schemeº
ldap://host:port/"Distinguished Name"?csv_list_attributes?search_scope?filter?extensions
                  ^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^ ^^^^^
                  Used as search base    comma-separated  search
                                         list of attr     scope:
                                         to retrieve    - base DN
                                                        - one (level)
                                                        - sub (tree)

ºDirectory Schemaº
- set of rules (definitions and constraints) concerning
  the structure of the directory information tree (DIT),
  or what information the server can hold.
  - Attribute Syntaxes: Provide info about the kind of info that can be stored in an attribute.
  - Matching Rules    : Provide information about how to make comparisons against attribute values.
  - Matching Rule Uses: Indicate which attribute types may be used in conjunction
                        with a particular matching rule.
  - Attribute Types   : Define an object identifier (OID) and a set of names that may be
                        used to refer to a given attribute, and associates that attribute with a
                        syntax and set of matching rules.
  - Object Classes    : Define named collections of attributes and classify them into sets of
                        required and optional attributes.
                        ObjectClasses can be inherited.
  - Name Forms        : Define rules for the set of attributes that should be included in the
                        RDN for an entry.
  - Content Rules     : Define additional constraints about the object classes and attributes
                        that may be used in conjunction with an entry.
  - Structure Rule    : Define rules that govern the kinds of subordinate entries that a given
                        entry may have.

BºNOTEº: Clients may learn about the schema elements that the server supports
         by retrieving an appropriate subschema subentry.

- A schema for representing individual people within organizations is termed a white pages schema.

ºAccess control is not standardizedº  though there are commonly used models.

ºLDAP extension pointº
  - define new operations.
  - modify requests/responses (sort results,...)
  - New search scopes and Bind methods can be defined.
  - new attributes options modifying their semantics.
  - ...

ºAccess protocolº
- As LDAP has gained momentum, vendors have provided it
  ºas an access protocol to other servicesº
  For example, Unix user and group information (via PAM, NSS modules)
- LDAP is often used by other services for authentication.

ºUsageº
- two common styles of naming:
  - top level objects are the c= (country) object
    Ex:
                    l=Locality, ou=Some Organizational Unit, o=Some Organization,        c=FR
    cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US

  - top level objects are domains
    Ex:
    cn=Common Name, dc=example,  dc=com

Active Directory
Active Directory LDAP requires that names of directory objects be
formed according to RFC 1779 and RFC 2247:
- @[https://www.ietf.org/rfc/rfc2247.txt]
    This document defines an algorithm by which a name registered with
    the Internet DNS can be represented as an LDAP distinguished name.

    subdomain.com  ←→  dc=subdomain,dc=com

    The algorithm for transforming a domain name is to begin with an
    empty distinguished name (DN) and then attach Relative Distinguished
    Names (RDNs) for each component of the domain, most significant (e.g.
    rightmost) first. Each of these RDNs is a single AttributeTypeAndValue,
    where ºthe type is the attribute "DC"º and
          ºthe value is an IA5 string containing the domain name componentº

    Two LDAP object classes are also defined.
    - dcObject: to integrate into alreaded existing schemas,
                alowing the dc attribute to be present in an entry.
    -   domain: structural object class used for entries in which no
                other information is being stored

- @[https://www.ietf.org/rfc/rfc1779.txt]
    X.500/LDAP distinguished names (primary keys) are encoded in ASN.1.
    there is a need to have a user-oriented string representation of DNs.
    ("human to human")

    Standardised Keywords*             Exs:
    Key     Attribute (X.520 keys)     |CN=Christian Huitema, O=INRIA, C=FR
    ------------------------------     |CN=Christian Huitema; O=INRIA; C=FR
    CN      CommonName                 |˂CN=Christian Huitema; O=INRIA; C=FR˃
    L       LocalityName
    ST      StateOrProvinceName        |CN=James Hacker,
    O       OrganizationName           |L=Basingstoke,
    OU      OrganizationalUnitName     |O=Widget Inc,
    C       CountryName                |C=GB
    STREET  StreetAddress
                                       |OU=Sales + CN=J. Smith, O=Widget Inc., C=US
                                          |CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB
                                          |CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB

GPG
Gnu Privacy Guard
Sym file
encrypt
ºEncrypt/Decrypt from/to fileº
$ gpg --symmetric plainTextFile --output myEncFile.gpg  # ← Encrypt
$ gpg --decrypt -o -                                    # ← Decrypt to STDOUT
$ shred -n 2 -z -v plainTextFile                        # ← Safe delete

ºEncrypt/Decrypt from/to STDIN/STDOUTº
$ echo "MySecret Text" | gpg -c --batch --passphrase 1234 | base64 -w 0                    # ← Encrypt from STDIN
jA0EBw...u+8ykK
$ echo "jA0EBw...u+8ykK" | base64 -d | gpg -d --batch --passphrase 1234 2˃/dev/null
MySecret Text


- multi-level
example script:
TMP_LEVEL1=/tmp/level1Ciphered.base64 ; DECODE_LEVEL1=decodedlevel1  ; PASS_LEVEL1=/tmp/myPassLevel1
TMP_LEVEL2=/tmp/level2Ciphered.base64 ; DECODE_LEVEL2=decodedlevel2  ; PASS_LEVEL2=/tmp/myPassLevel2
TMP_LEVEL3=/tmp/level3Ciphered.base64 ; DECODE_LEVEL3=decodedlevel3  ; PASS_LEVEL3=/tmp/myPassLevel3
(
cat ˂˂ EOF
 secrets level 1
EOF
) | gpg -c --batch  --passphrase ${PASS_LEVEL1} | base64 ˃ ${TMP_LEVEL1}


(
cat ${TMP_LEVEL1}

cat ˂˂ EOF
 secrets level 2
EOF
) | gpg -c --batch  --passphrase ${PASS_LEVEL2} | base64 ˃ ${TMP_LEVEL2}


(
cat ${TMP_LEVEL2}

cat ˂˂ EOF
 secrets level 3
EOF
) | gpg -c --batch  --passphrase ${PASS_LEVEL3} | base64 ˃ ${TMP_LEVEL3}

cat ${TMP_LEVEL3}  | base64 -d | gpg -d --batch --passphrase ${PASS_LEVEL3} ˃ $DECODE_LEVEL3
cat $DECODE_LEVEL3 | base64 -d | gpg -d --batch --passphrase ${PASS_LEVEL2} ˃ $DECODE_LEVEL2
cat $DECODE_LEVEL2 | base64 -d | gpg -d --batch --passphrase ${PASS_LEVEL1} ˃ $DECODE_LEVEL1

echo "---- DECODED LEVEL 3 ------"
cat $DECODE_LEVEL3
echo "---- DECODED LEVEL 2 ------"
cat $DECODE_LEVEL2
echo "---- DECODED LEVEL 1 ------"
cat $DECODE_LEVEL1

-Priv.key mng
REF:
ºNEW KEYPAIRº
$ gpg --gen-key       # defs: RSA 2048bit, no-expire
# (enter name+email when prompted)         ^^^^^^^^^
                                           Recommended ˂=2 years
                                           Once expired it can be extended
                                           providing  key (and passphrase).

$ gpg2 --list-keys   #           ← ºLIST PUBLIC KEYSº
/home/juven/.gnupg/pubring.gpg
------------------------------
pub   1024D/C6EED57A 2010-01-13
uid                  OldMcDonalds˂old.mcdonalds@farm.com˃
sub   2048g/D704745C 2010-01-13
      ^^^^  ^^^^^^^^
     length   keyid

$ gpg2 --list-secret-keys #      ← ºLIST  KEYSº
/home/juven/.gnupg/secring.gpg
------------------------------
sec   1024D/C6EED57A 2010-01-13
uid                  OldMcDonalds
ssb   2048g/D704745C 2010-01-13


$ gpg2 -ab temp.java #            ← ºSIGNING A FILEº
           ^^^^^^^^^                -a create ASCII armored output
           output to temp.java.asc  -b make detached signature

$ gpg2 --verify temp.java.asc #   ← ºVerify new signatureº


KEYSERVER="hkp://pool.sks-keyservers.net"
$ gpg2 --keyserver ${KEYSERVER}   ← º"PUSH" PUB.KEYº
  \ --send-keys C6EED57A
$ gpg2 --keyserver ${KEYSERVER}   ← º"PULL" PUB.KEYº
  \ --recv-keys C6EED57A

ºEXPIRE A KEYº
$ gpg2 --edit-key A6BAB25C
... Secret key is available.
pub  2048R/A6BAB25C  created: ...  expires: ...
     trust: ultimate      validity: ultimate
sub  2048R/DD289F64  created: ...  expires: ...
     Juven Xu (for testing) ˂test@juvenxu.com˃
...
gpg˃ Oº1º  # ← Choose key
pub  2048R/A6BAB25C  created: ...  expires: ...  usage: SC
     trust: ultimate      validity: ultimate
sub  2048R/DD289F64  created: ...  expires: ...  usage: E
(1)* Juven Xu (for testing) ˂test@juvenxu.com˃

gpg˃ Oºexpireº
→ ...
→ Please specify how long the key should be valid.
        0 = key does not expire
      ˂n˃ = key expires in n days
     ...
gpg> Oºsaveº
(push again to publick hkp serser)

ºMaven problem with Signature SUBKEYsº
- Some PGP tools generate a sub-signing priv.key
  splited from the primary key (seed key).
- Maven and other only recognise the primary key,
  not subkeys. Deleting Singing subkey will force
  GPG to use the primary key.
$ gpg2 --edit-key A6BAB25C
...
pub  2048R/A6BAB25C  created:... usage: SC
                   trust: ultimate      validity: ultimate
sub  2048R/DD289F64  created:... ºusage: E  # E:Encryptionº
sub  2048R/8738EC86  created:... ºusage: S  # S: Signing  º

gpg> Oºkey 2º (index start at 0)
...
gpg> Oºdelkeyº  # (or ºrevokeº if already published)
gpg> Oºsaveº

S/MIME:
- Uses Crypto.Message (PKCS#7) and pub.key infraestructure for encryption and signing
- PGP/SMIME EFail vulneravility

Off-The-Record
 Messaging(OTR)
@[https://en.wikipedia.org/wiki/Off-the-Record_Messaging]
- protocol for securing/authentication/encrypting instant messaging communication amongst people.
 Encrypts messages, prevents eavesdroppers, authenticates peers to each other.
 It also provides OTR provides forward secrecy and malleable encryption.

- OTR uses a combination of AES 128bits sym-key algorithm,  1536-bits group-size Diffie–Hellman
  and the SHA-1 hash function.
- The primary motivation behind the protocol was providing deniable
  authentication for the conversation participants while keeping
  conversations confidential, like a private conversation in real life, or
  off the record in journalism sourcing. This is in contrast with
  cryptography tools that produce output which can be later used as a
  verifiable record of the communication event and the identities of the
  participants. The initial introductory paper was named "Off-the-Record
  Communication, or, Why Not To Use PGP".[1]
- The OTR protocol was designed by cryptographers Ian Goldberg and Nikita
  Borisov and released on 26 October 2004.[2] They provide a client library
  to facilitate support for instant messaging client developers who want to
  implement the protocol. A Pidgin and Kopete plugin exists that allows OTR
  to be used over any IM protocol supported by Pidgin or Kopete, offering an
  auto-detection feature that starts the OTR session with the buddies that
  have it enabled, without interfering with regular, unencrypted

Dmarc sec mail
@[http://www.eweek.com/security/dmarc-email-security-adoption-soars-as-us-government-deadline-hits]]
DMARC is a protocol that helps protect the integrity and
authenticity of email. DMARC is not a single technology but rather
is a combination of several components, including the Sender Policy
Framework (SPF) and Domain Keys Identified Email (DKIM), to help
verify email authenticity. There are also different levels of DMARC
policies. The "p=none" policy enables organizations to monitor
their email systems for senders, while the "p=reject" policy will
block non-compliant messages completely. BOD 18-01 mandates the use
of the p=reject policy by Oct.16.

PKCS
PKCS: Set of "high-level" "Public Key Cryptography Standards":
- ºPKCS #1º math. properties + format of RSA pub/priv keys, and
  basic algorithms and encoding/padding schemes for RSA
  (de/en)cryption,  producing/verifying signatures.
- ºPKCS #3º Diffie–Hellman Key Agreement Standard
- ºPKCS #5º Password-based Encryption Standard
- ºPKCS #7º Cryptographic Message Syntax used to sign
  and/or encrypt messages under a PKI
  See also (PKCS #7 derived)Cryptographyc Message Syntax
- ºPKCS #8 º to carry private certificate kye (and matching pub.key)
- ºPKCS #9 º Defines selected attribute types for use in PKCS #6,#7,#8,#10
- ºPKCS #10º  Certification Request Standard
- PKCS #11
  Cryptographic (Athentication) Token Interface
  ("Cryptoki") API defining a generic interface to cryptographic tokens
- ºPKCS #12º Personal Information Exchange Syntax defining file
  format commonly used to store private keys, protected with a password-based
  symmetric key. Used by:
  - Java key store
  - client auth. certs in Firefox, Apache Tomcat
- ºPKCS #15º idetification through tokens allowing users to identify
  themselves to applications, independent of the application's Cryptoki
  implementation (PKCS #11) or other API

  See also:
  - ISO 7816 standard for electronic identification cards with contacts, especially smart cards.
    @[https://en.wikipedia.org/wiki/ISO/IEC_7816]

OASIS STANDARDS

XAdES
@[https://www.w3.org/TR/XAdES/]
XML Advanced Electronic Signatures (XAdES)

DSS
OASIS Digital Signature Services (DSS)
@[https://ec.europa.eu/cefdigital/wiki/pages/viewpage.action?pageId=46992515]
DSS (Digital Signature Services) is an ºopen-source software libraryº
for ºelectronic signature creation and validationº. DSS supports the creation and
verification of interoperable and secure electronic signatures in line with
European legislation. In particular, DSS aims to follow the eIDAS Regulation
and related standards closely.

DSS can be re-used in an IT solution for electronic signatures to ensure that
signatures are created and verified in line with European legislation and
standards. DSS allows re-use in a variety of different ways: in an applet, in
a stand-alone application or in a server application. DSS can also be used as
a reference implementation for IT solutions which do not directly re-use it.
Demos are also available to assist the use of DSS as a reference implementation.

The library, ºrealised in Javaº, is open-source, available to all Member States
, businesses and citizens for re-use in electronic signature solutions. It is
continuously updated and maintained to anticipate and follow developments in
regulations and standards.

Anyone can integrate it and redistribute it under the terms of the Lesser
General Public License (LGPL 2.1).

In accordance with ETSI standards, DSS supports various document and
signature formats including PAdES, XAdES, CAdES and ASiC and is compliant
with Implementing Decision 2015/1506/EU. A “cook-book” is also provided with
documentation targeting implementers/developers and aiming at facilitating
the integration and use of DSS in their applications.


AES
@[https://en.wikipedia.org/wiki/Advanced_electronic_signature]
-- PAdES(PDF) format
@[https://en.wikipedia.org/wiki/PAdES]
-- XAdES(XML) format
@[https://en.wikipedia.org/wiki/XAdES]
  The Cryptographic Message Syntax (CMS) is the IETF's standard
  for cryptographically protected messages. It can be used to
  digitally sign, digest, authenticate or encrypt any form of
  digital data.
-- CAdES(CMS) format
@[https://en.wikipedia.org/wiki/CAdES_(computing)]
@[https://en.wikipedia.org/wiki/Cryptographic_Message_Syntax]
  Extensions to 'Cryptographic Message Syntax'
- - ASiC format
@[https://en.wikipedia.org/wiki/Advanced_electronic_signature]
  ASiC Baseline Profile. ASiC (Associated Signature Containers)
  specifies the use of container structures to bind together one
  or more signed objects with either advanced electronic signatures
  or time-stamp tokens into one single digital (zip) container.

X.509 TimeStamp Protocol
@[https://tools.ietf.org/html/rfc3161]

- RFC describes format for request and responses sent to a
  Time Stamping Authority (TSA)
- It establishes several security-relevant requirements for TSA
   operation

- TSA service:
  - provides proof-of-existence:
    - Some data datum existed before a particular time.
      (only the hash representation is used by the protocol)
  - Can also be used as the base for Non-repudiation services [ISONR]
  - only time-stamp a hash representation of the datum, i.e., a
  - CAs will issue custom certificates for this service indicating
    that it is exclusively used for this TSA purpose


2.2. TSA Transactions

A → TSA: request1
         --------
         type:TimeStampReq

TSA → A: response1
         ---------
         TimeStampResp
           TimeStampToken(TST)

A →   A:- verify status error
        - verify fields contained in the TimeStampToken
        - verify validity of digital signature
        - verify that what was time-stamped corresponds
           to what was requested
        - verify that the TimeStampToken contains:
          - the correct certificate identifier of the TSA
          - the correct data imprint
          - the correct hash algorithm OID.
        - verify time included in the response against
          local trusted time reference

See original RFC for extended details

Think lib
crypto for
non-experts
@[https://www.infoq.com/news/2018/09/google-tink-cryto-ios-android]
- Crypto.libr for *non cryptographic experts
- cross-platform
- developed by experts to help developers implement cryptography
  correctly ºwithout being cryptographic expertsº.
- version 1.2 adds support for Cloud, Android, and iOS platforms,
  C++ and Objective-C.
- stress cryptographic libraries against known attacks:
  - biased nonces
  - invalid curves
  - ...
-OºTink provides support for key managementº
 Oºincluding key versioning/rotation/remote key management systems(KMS):º
 Oº-  Currently, the following KMSes are supported:º
 Oº  Google Cloud KMS, Amazon KMS, Android Keystore, Apple iOS KeyChain (planned)º



- ensure crypto.algorithms behave as expected (DSA, RSA, AES-EAX, ...)

- Tink strives to make as explicit as possible what security guarantees each
  provided API gives:
  - For example, if a given operation is safe against chosen-ciphertext attacks,
    this is displayed in the interface and that same guarantee has to be satisfied
    by each primitive used to implement it.

- currently four cryptographic operations are provided, implemented by specific primitives:
  - authenticated encryption with associated data (primitive: AEAD)
  - message authentication codes (primitive: MAC),
  - digital signatures (primitives: PublicKeySign and PublicKeyVerify)
  - hybrid encryption (primitives: HybridEncrypt and HybridDecrypt).

- Each operation has an associated set of minimal properties and a guarantee.
  A primitive can have multiple implementations and the user chooses the actual
  implementation to use by instantiating a key of a corresponding type.

Wallets

Wallet vs Vault
In Vaults, secrets are kept safe until needed by an application.

In wallets, the secrets (ideally) are never exposed outside the wallet.
Unsigned transactions come in, then signed transactions come out.
The wallet usually have aditional utility functions like "address agenda",
"browser of transactions", ...

A wallet makes use of a vault. (A vault is a "layer down the stack")

Vaults are generic for any type of app.

Wallets are mostly used for blockchain-like applications.

Wallet vs Smart-Cards
  - Some types of Smart-Cards can be considered a type of wallet, in
  the sense that they can be used to sign content using a hardware
  protected private-key.
  - Still Smart-Cards are mostly designed with Authentication as
    primary use-case, to provide that the user accessing a website,
    a bank terminal, ... is the real authorized user.
  - Wallets is mostly a blockchain concept, while smart-card is
    a general device that can be used for many purposes
    (Web TLS or SSH Client Authentication, PGP signature, ...)
  - Wallets are designed with TX signature in mind.
    A wallet protects the private key, signs the TXs and probably
    has a display that shows what's going to be signed and a
    physical button that the user must "click" in order to confirm
    the transaction.
  - Stealing of the wallet can mean stealing of the money.
  - Stealing of the smart-card means money can be stealed until
    the smart-card is cancelled.

Deterministic Wallet
@[https://en.bitcoin.it/wiki/Deterministic_wallet]
A deterministic wallet is a system of deriving keys from
a single starting point known as a seed. The seed allows
a user to easily back up and restore a wallet without
needing any other information and can in some cases allow
the creation of public addresses without the knowledge of
the private key. Seeds are typically serialized into
human -readable words in a Mnemonic phrase.

JS Carbon Wallet
@[https://en.bitcoin.it/wiki/CarbonWallet]

- No server side storage, ºprivate keys are generated from º
 ºthe passphrase and only exist in the memory of the browserº
- Deterministic key generation: Write down the passphrase
  generated for you and it's all you need
- Transactions are signed locally in the browser: Your
  private keys are not shared with the server. You do not
  have to trust the server with your money
- Privacy: No need to register a passphrase is all that
  is required
- Public code hosted on Github which anyone can audit

Keepass
@[https://keepass.info/]
- free, open source, light-weight and easy-to-use password manager in a ¿secure?
- All passwords are stored in a single database file (encrypted with AES/Twofish)
  locked with one master key or a key file.
              ^^^^^^^^^^^^^^
            (The only pass needed to remember)

Hardware wallets

Lattice 1
@[https://blog.gridplus.io/lattice1-sdk-and-generalized-signatures-e17da7cf65d7]
Lattice 1:
  generalized "remote ("WiFi",...) signer" for
  cryptocurrencies, digital identity, and more.
  (The priv.key is never transmited outside the hardware,
   unsigned docs come in and signed docs come out)

ºREMOTE SIGNINGº                                     | ºSEPARATING THE SIGNER:º
wallet application technical components:             | STEP 1:
ºUSER INTERFACEº: It interfaces with both            | - let's consider moving TX signer to cloud machine.
  - persisted user data: addresses, TX history,...   |   =˃ you have to store your private key on the cloud
  - network nodes: allow to display account info     | STEP 2:
ºTX BUILDERº    : Applies the network protocol       | -Move TX builder in the cloud too
  to convert parameters (amount, recipient address   |
  , ...) into one or more hashes that make up a TX.  | """In Lattice1 we have separated the protocol and
   Note: in Ethereum, each TX is represented by a    | cryptographic functionality away from the application
     single hash, whereas in Bitcoin each consumed   | layer ... Of course keys are in a secure chip within
     input has its own hash to sign,  there can be   | the Lattice1."""
     one or many inputs per Bitcoin transaction.
ºTX SIGNERº     : sign TX hashes with private key.


ºSECURING COMPONENTS AND SEPARATING CONCERNSº
- The Lattice1 introduces a more usable, robust, and
  secure connection between application ("wallet GUI")
  and TX builder/signer components.

 ┌────→ "GUI Apps in Cloud"
 │
 ↓
Standard Chip ←─────────→ Secure Chip 1 ←────→ Secure Chip 2
    ↑                        ↑                    ↑
-connect to            - Build TX hashes      - Store priv.keys
 outside apps          - Placed on device     - Make signatures
- request signatures                          - Placed on device
- Lattice1 addition:                            and each Safe Card
  - facilitates (wireless) communication app←→Sec.Chip

GUI App Connection:
STEP 1: App    generates EC25519 key pair (just once)
STEP 2: Chip 1 generates EC25519 key pair (for each new app pairing)
STEP 3: PAIRING: ECDH Key exchange is use to interchange
               App.pub_key ←→ Chip1.pub_key_for_app1


     _       _ _
  __| | __ _(_) |_   _     _   _ ___ ___  __ _  __ _  ___
 / _` |/ _` | | | | | |   | | | / __/ __|/ _` |/ _` |/ _ \
| (_| | (_| | | | |_| |   | |_| \__ \__ \ (_| | (_| |  __/
 \__,_|\__,_|_|_|\__, |    \__,_|___/___/\__,_|\__, |\___|
                 |___/                         |___/

""app wants to pair with a user’s Lattice1 device.""

ºSTEP 1º: Find device by serial number
- find the user's agent based on a serial number.
  (not needed if Lattice1 can connect with the app
   on a local area network).

ºSTEP 2º: Transfer a Secret Code (Out of Band)
Once the app can talk (insecurely) to the Lattice1,
- app generates secret code, signs hash with that code
  using a secp256k1 private key (is different to the EC25519
  used for encryption/decription)
- User presses "Pair" button:
- Appt sends a message to Lattice1 device ºrequesting pairingº start
- Lattice1 displays a place for the user to enter
  the same code that is displayed on the application.

- With correct code lattice1 can recover secp256k1 public key
  used to sign the hash and stores both that and the curve25519
  public key, which is also sent in the payload.

ºSTEP 3º: Establish a Read-Only Permission
(Pairing is done at this point)
- Lattice1 gives app permission to view addresses,
  request signatures (that must be authorized on device screen)
  for one-off (vs automated) signatures,...

ºFINAL STATE OF A PAIRINGº

APP:                     LATTICE1 Dev:
32-byte priv.key

Pairing registry:
- app1.pub_secp256k1 (used to  check future request signatures)
- app1.pub_EC25519   (sed to decrypt future request payloads  )

(App has now established a secure connection)

some complex details avoided (using 1-time keys for future requests,
  separate pairing code generated by the Lattice1).

ºREMOTE SIGNINGº
Now app can be used as a generalized TX Signer, just like any other hardware wallet. Unlike other
hardware wallets, however, the paired application is capable of communicating with the device
wirelessly.

We are now able to request a signature on some piece of data, which is of course parameterized
and built in the CHip 1 (TX  Builder)

ºMANUAL REMOTE SIGNINGº
As mentioned above, the pairing process also creates a minimal "permission". The application may request a
signature using this permission in a way similar to existing hardware wallet TXs:

- the Lattice1 device displays transactional data to the user
  and must wait for the user to hit “accept” on the touch
  screen.

However, there are a few technical differences that are worth noting:

- data must conform to a pre-defined "schema".
 (periodically released as use cases emerge, like
  ETH transfers and BTC transactions (P2SH|P2PKH)

AUTOMATIC REMOTE SIGNING: (Ex. ecurring payments, keep-alive messages)
- Use of "recurring permissions", which require a pre-defined schema
 (just like manual signatures) in addition to a set of "rules" on the
 data that will be signed in the future. Such a permission might look like this:

{
  schemaIndex: 0,     ← published "schema" for Eth TX (0)
  typeIndex: 0,       ← ETh TX type.  0: standard TX (empty data)
  rules: [
    null    , null                                        , null,
    null    , null                                        , null,
    null    , null                                        , null,
    'equals', '0x39765400baa16dbcd1d7b473bac4d55dd5a7cffb', null,  ←  recipient
    'equals', 1000                                        , null,  ←  wei ammount
    'equals', ''                                          , null,
       ^                        ^                            ^
    typeOfRule             value1                           value2
  ],
  timeLimit: 10000                                                ← seconds elapsed between requests
}

specific rules [ nonce, gas, gasPrice, to, value, data ]

. In this case, the requester can only send a request once every 10,000 seconds. One second (or more) too early and the request will be denied.
Application SDK

All of the previously discussed functionality is made possible through a Grid
+ Software Development Kit (SDK); this SDK will be released as an open source
node.js module. We hope that developers wanting to build applications with a
separated, internet-connected, secure signing service will experiment with
the SDK and integrate with the Lattice1 device. Although Grid+ is building a
mobile wallet application, this too will be open sourced as an example of how
to leverage the Grid+ SDK.

Although the API is not finalized yet, the below Javascript snippet is an
example of what using the SDK may look like:

const Sdk = require('gridplus-sdk');
const sdk = new Sdk({ btcNode: 'localhost:48332', ethNode: 'localhost:8545' });


const req = {
  type: 'eth-transfer',
  rules: {
    value: { 'equals': 1000 },
    to: { 'equals': '0x39765400baa16dbcd1d7b473bac4d55dd5a7cffb' }
  },
  interval: 10000
}

sdk.createAutomaticPermission(req, (err, res) =˃ {
  ... do stuff ...
})

Keeping it General

Although this article mostly discusses the Lattice1 remote signing
functionality in the context of cryptocurrency transfers, it is important to
highlight that using an abstracted “signer” allows applications to request
signatures on any data that is parametrizable. One can imagine, for example,
a data schema that represents parameters of a legal contract:

"Top" hard.Wallets
(Updated to 2018)

ºLedger Nanoº
@[https://shop.ledger.com/products/ledger-nano-s]
- securised key store system:
  - WYSIWYS/BOLOS:
  - Fully-certified by ANSSI, the French cybersecurity agency.
  - BºBackup:º crypto assets stay safe even if you lose Ledger Nano S.
    A confidential recovery phrase backs up your device,
    and your accounts can easily be restored on any Ledger device.

ºKeepKeyº
- Controlled through Google Chrome.
@[https://shapeshift.io/keepkey/]
- RºRecovery method?º

ºSafe T-Mini (Archos)º
 Notre avis complet sur le Safe T-mini
@[https://shop.archos.com/es/hardware-wallet/588-archos-safe-t-mini.html]
- RºRecovery method?º


ºLedger Blueº
@[https://shop.ledger.com/products/ledger-blue]
- architecture double-chip.
- To validate TXs, it can comunicate through USB/Bluethooth.
- Targeting business.
- "Big" screen for easy ussage.
- RºRecovery method?º

ºCoolBitX CoolWalletº
@[https://www.coolwallet.io/]
- Credit Card format
- RºRecovery method?º

Trezor Wallet
@[https://en.bitcoin.it/wiki/TREZOR]
- BIP 0032 Deterministic hardware wallet.
- TREZOR is basically a small computer. It is designed to
  protect your private keys from possible online and
  offline risks.
- RºRecovery method?º

Hardware Security Module(HSM)
(Vaults, encrypt modules,...)

PROTOCOL/APIs SCHEMA
        ┃  COMMUNICATION          ┃
        ┃ APIs/PROTOCOLS          ┃
        ┃                         ┃
        ┃ Standard Cross-Platform ┃
        ┃   -ºPKCS#10º            ┃
        ┃   -OpenSSL              ┃ HARDWARE
        ┃   -KMIP                 ┃ SECURITY
APP     ┃                         ┃  MODULE
        ┃ Non-Standard and/or     ┃
        ┃ Non-Cross-Platform      ┃
        ┃   -Java JCE             ┃
        ┃   -MS/CAPI              ┃
        ┃   -"others"             ┃

                        ºPKCS#11 flowº
──────────────────────────────────────────────────────────────────────────────────
     SOFTWARE                 ┇            HARDWARE
______________________________    ┃   ____________________________________________
                              ┃       ┌─────────────┐  ┌───┐  ┌──────────────────┐
App ←→ Driver PKCS#11 ←→ OpenSC → ┃ ←→│Crypto OpenSC│←→│Phy│←→│SmartCard ISOXXXX │
                              ┃       └─────────────┘  └───┘  └──────────────────┘

Ex:
- Securosys HSM, used by R3 Corda to encrypt and sign offline.
  - REF:
  @[https://www.securosys.com/en/products/primus-hardware-security-modules-hsm]
  @[https://www.youtube.com/watch?v=ydMMb1wcCT0&list=PLi1PppB3-YrVeHKIhNxm3_4NvO0AFSvWr] (~8min:00)

Arch.considerations
for cryptanalytic hardware
@[https://people.eecs.berkeley.edu/~daw/papers/hwkeysearch96-www/chap-10_local.html]

yubikey
@[https://www.yubico.com/products/yubikey-hardware/]
@[https://github.com/drduh/YubiKey-Guide]
""the industry's #1 security key, enabling strong
two-factor, multi-factor and passwordless authentication."""

- Works with hundreds of services incluing Windows/Mac login,
  Gmail, Dropbox, Facebook, Salesforce, Duo, ...

- Multi-protocol support: FIDO2, U2F, Smart card, OTP

USB Armory
@[https://inversepath.com/usbarmory]
The following example security application ideas
illustrate the flexibility of the USB armory concept:

- Hardware Security Module (HSM)
- encrypted file storage with malware scanning,
  host authentication and data self-destruct
- USB firewall, bridging built-in receptacle and plug ports
- OpenSSH client and agent for untrusted hosts (kiosk)
- router for end-to-end VPN tunnelling, Tor
- password manager with integrated web server
- electronic wallet (e.g. pocket Bitcoin wallet)
- authentication, provisioning or licensing token
- portable penetration testing platform
- low level USB security testing

Enterprise HSM
@[https://safenet.gemalto.com/data-encryption/hardware-security-modules-hsms/protectserver-security-module/]

             SECP256K1                      Crytographic APIs
           │              ┌──────────┬────────────────┬─────────────────────┬────────┐
           │              │ PKCS#11  │ Java (JCA/JCE) │ Microsoft CAPI  CNG │ OpenSSL│
───────────│──────────────┼──────────┼────────────────┼─────────────────────┼────────┤
nChiper    │              │          │                │                     │        │
           │              │          │                │                     │        │
Gemalto    │              │          │                │                     │        │
(LunaHSM)  │              │          │                │                     │        │
           │              │          │                │                     │        │
....

MultiFacto authentication

Universal 
Second Factor
(U2F)
- See also:
@[https://en.wikipedia.org/wiki/Multi-factor_authentication]




@[https://www.yubico.com/solutions/fido-u2f/]
internet open auth. enabling users to securely access services
ºwith one single sec.key and with no drivers or client software neededº

u2f at github.com/google
See also: Universal Authentication Framework (UAF) protocol
- vision: "take strong public key crypto to the mass market"
- Successfully deployed by Facebook, Gmail, Dropbox, GitHub, Salesforce.com, the UK government,
and many more.

Smart Cards

DS/EN 14890-1 Standard
@[https://standards.globalspec.com/std/1167872/DS/EN%2014890-1]

Part 1 of this series specifies the application interface to Smart Cards
during the usage phase,ºused as Secure Signature Creation Devices (SSCD) º
describing the mandatory services ... covering the
ºsigning functionº, storage of certificates, related user verification,
establishment and use of trusted path and channel, requirements for
key generation...
the functionality of CWA 14890-1 is enhanced in the following areas:
- ºDevice authentication with Elliptic Curves (ELC)º
  ºfor existing asymmetric authentication protocolsº
  º(RSA Transport, Privacy Protocol)               º
- Secure Messaging Tags
- Further hash algorithms (SHA2-family)
- Use of AES in auth protocols and secure messaging.

GNUPGP SC
-@[https://www.commoncriteriaportal.org/cc/]
   Supporting Documents related to Smart Cards and similar devices
   Document number     Document title  Class
   2006-06-001         Rationale for Smart cards and similar devices
   CCDB-2010-03-001    Guidance for smartcard evaluation v2.0  Guidance
   CCDB-2014-04-001    Security Architecture requirements (ADV_ARC) for
                       smart cards and similar devices (Mandatory)
   CCDB-2009-03-002    Application of CC to Integrated Circuits v3.0  (Mandatory)
   CCDB-2012-04-001    Composite product evaluation for Smartcards    (Mandatory)
                       and similar devices
   CCDB-2007-09-02     ETR-template lite for composition Guidance
   CCDB-2012-04-004    Security Architecture requirements (ADV_ARC)   (Guidance)
                       for smart cards and similar devices - Appendix 1
   CCDB-2013-05-001    Minimum ITSEF Requirements for Security  (Mandatory)
                       Evaluations of Smart cards and similar devices
   CCDB-2013-05-002    Application of Attack Potential to Smartcards  (Mandatory)

- GNUPGP Smart Card specs
@[https://gnupg.org/ftp/specs/]
@[http://cardwerk.com/iso-7816-smart-card-standard/]

- Extracted from @[https://en.wikipedia.org/wiki/Smart_card]
  """PGP SmartCard is the most widely used
  Crypto Commands include:
    - PSO: COMPUTE DIGITAL SIGNATURE
    - HASH ALGORITHMS
    - DigestInfo for RSA
    - PSO: DECIPHER
    - PSO: ENCIPHER
    - INTERNAL AUTHENTICATE
      + Client/Server Authentication
    - GENERATE ASYMMETRIC KEY PAIR
    - GET CHALLENGE
    - TERMINATE DF
  """

Related:
- GPG SmartCard for SSH Authentication
@[https://www.grepular.com/Smart_Cards_and_SSH_Authentication]
  ºSSH KEY SETUPº
  ────────────────────┬──────────────────────────────────────
  STANDARD(SOFTWARE)  │ PGP (HARDWARE)
  SSH KEYGEN          │ SMART-CARD:
  ────────────────────┼──────────────────────────────────────
            GENERATING THE KEYS
  ────────────────────┼──────────────────────────────────────
  $ ssh-keygen ...    │ (Install GnuPG 2 first)
                      │   $ gpg –gen-key  # Generate a keypair:
                      │   $ gpg –edit-key # ← Add ºauthentication subkeyº
                      │   ˃ addkey        # ←
                      │   ˃ keytocard     # ← transfer private part of subkey to smart-card
                      │                   #   A stub referencing the subkey is left behind
                      │                   #   with your on disk keypair.
                      │
                      │ - Whenever you try to use that subkey, the system
                      │   will request that you insert the smart card.
                      │
  ────────────────────┼──────────────────────────────────────
            ADDING AUTH.SUBKEY TO SSH LIST OF AUTHORIZED KEYS
  ────────────────────┼──────────────────────────────────────
  $ ssh-copy-id ...   │  ("gpgkey2ssh" utility is provided by the gnupg-agent package )
                      │  Alt 1:
                      │    $ gpgkey2ssh $gpgSubkeyID_for_sshAuth \
                      │      → output_ssh_formated_pubkey
                      │        ^^^^^^^^^^^^^^^^^^^^^^^^^^
                      │    C+P to remote "~/ssh/authorized_keys" file
                      │
                      │  Alt 2: (If the auth.subkey is on public gpg keyservers):
                      │    $ gpg --recv-key 0018461F
                      │    $ gpgkey2ssh 13990B29 ˃˃ ~/.ssh/authorized_keys
  ────────────────────┴──────────────────────────────────────

  AUTHENTICATING USING THE SMART CARD
  (how do we get the OpenSSH client to use the smart card)

  ────────────────────┬──────────────────────────────────────
  STANDARD(SOFTWARE)  │ PGP (HARDWARE)
  SSH KEYGEN          │ SMART-CARD:
  ────────────────────┼──────────────────────────────────────
  (setup ssh-agent)   │ gpg-agent has been designed to speak
                      │ the same protocol as ssh-agent
                      │
                      │ - STEP 01:
                      │   stop ssh-agent process
                      │ - STEP 02:
                      │   add "enable-ssh-support" to
                      │   ~/.gnupg/gpg-agent.conf
                      │
                      │ ( OpenSSH client should start talking
                      │   to gpg-agent now )
                      │
                      │ - STEP 03:
                      │   $ ssh-add -l
                      │ ( You should see that the key you
                      │   generated previously is mentioned
                      │   only when the S.C. is inserted!!! )
                      │
                      │ you’re done!!
                      │ ssh'ing to a remote machine with your pubkey
                      │ will ask to type your pin on the smart-card
                      │ reader.

  (See original ref for Windows/Putty setup)


- List of Implementations of the OpenPGP application for smart cards
@[https://incenp.org/notes/2016/openpgp-card-implementations.html]

- @[https://g10code.com/]
  """Founded by the principal author of GnuPG ...
     we provide custom development, enhancements
     and audits of cryptographic software.
     An ongoing effort of ours is the development
     and maintenance of GnuPG and related software."""
  - OpenPGP (Smart)Card Specs:
  @[https://g10code.com/p-card.html]

  - @[https://openpgpcard.net/]
  RºWARN: Does not include displayº
  - Hardware cryptocurrency wallet
  - OpenPGP smart card
  - U2F authenticator
  - One-time password generator

CardPeek
@[http://pannetrat.com/Cardpeek]
- Linux/Windows/Mac OS X tool to read the contents
  of ISO7816 smart cards. It features a GTK GUI to
  represent card data is a tree view, and is extensible
  with a scripting language (LUA).

- The goal of this project is to allow smart card owners to
  be better informed about what type of personal information
  is stored in these devices.

- As of version 0.8.2, this tool is capable of reading the contents
  of the following types of cards:

- EMV "chip and PIN" bank cards, including:
      VISA, MasterCard, CB and UK Post Office Account contact cards;
      PayWave (VISA) and PayPass (MasterCard) contactless cards;
- Electronic/Biometric passports, which have an embedded contactless chip;
- The Belgian eID card;
- Calypso transport cards including:
      Navigo transport cards used in Paris;
      MOBIB cards used in Brussels;
      RavKav cards used in Israel;
      VIVA cards used in Lisbon;
- GSM SIM cards (without USIM data used in recent cards);
- Vitale 2, the French health card.
- Moneo, the French electronic purse;
- Driver Tachograph cards;
- OpenPGP Cards (beta);

Some important card types are missing or need further development,
however, this application can be modified and extended easily to your
needs with the embedded LUA scripting language

OpenCryptoJC.org
@[http://opencryptojc.org/]
(Speed Up JavaCard Dev)
- [Video] Unchaining the JavaCard Ecosystem (2018-02-22)
Project providing convinient libraries for JavaCard development
including Integers, Big Numbers, Elliptic Curves and Profilers.

Java Card Comparision

Security token
@[https://en.wikipedia.org/wiki/Security_token]
- Physical devices used to gain access to an
  electronically restricted resource
- Used in addition to or in place of a password like a
  wireless keycard to open/unlock doors,...
- All tokens contain some secret information used to
  prove identity
- There are four ways in which this info. can be used:
  - Static password: token containing a password
    transmitted for each authentication (vulnerable to
    replay attacks)
  - Syncrhonous dynamic password token, using a
    timer to rotate through various combinations. Need
    time synchronization with server
  - Asyncrhonous password token generating One-time
    password (no clock involved)
  - Challenge-response token using pub.key
    cryptography

Trusted Exec Env
@[https://en.wikipedia.org/wiki/Trusted_execution_environment]
@[https://en.wikipedia.org/wiki/Trusted_Platform_Module]

Intel SGX
@[https://software.intel.com/en-us/blogs/2013/09/26/protecting-application-secrets-with-intel-sgx]
RºWARN: SGX was vulnerable to Meltdown and Spectre hardware bugsº
CPU instruction set allowing user-level code to allocate
private regions of memory (enclaves) protected from
processes running at higher privilege levels. (secure
remote computation, secure web browsing, DRM).

SGX is a set of instruction set extensions for CPUs
released in Fall 2015 and available on recent CPUs. The
key ability SGX provides is the notion of confidential,
private execution with integrity guarantees. In essence,
the chip has a special construct called an enclave. An
enclave is like an ordinary program, except that the
memory contents of an enclave are encrypted whenever they
are off-chip, and accessible only on-chip, and only while
the special enclave code is running. Further, the
decryption keys are available solely to code with a
certain hash: if you or a hacker were to hack the enclave
code and change its hash, that hacked code will no longer
have access to the encryption keys, repelling attacks. As
a result, this ingenious technology does not permit anyone
, even the owner of the machine who can modify the code
arbitrarily, to peek at the contents of the enclave or to
modify execution within an enclave. Further, the SGX
hardware enables remote attestation, that is, the ability
to prove to a remote computer that a given enclave is
running a particular software distribution. In essence,
the chip is able to issue a statement that says "I
guarantee to any remote party that I am running this code
with this particular hash," which is a critical
bootstrapping mechanism. Teechan is built on these two
underlying features, which, together, provide a trusted
execution environment (TEE).

Vault services&KMS

HashiCorp Vault Project
"""HashiCorp Vault secures, stores, and tightly controls
  access to tokens, passwords, certificates, API keys, and
  other secrets in modern computing. Vault handles leasing,
  key revocation, key rolling, and auditing. Through a
  unified API, users can access an encrypted Key/Value
  store and network encryption-as-a-service, or generate
  AWS IAM/STS credentials, SQL/NoSQL databases, X.509
  certificates, SSH credentials, and more. "

  Vault@Github

Keywhiz
@[https://square.github.io/keywhiz/]

Crypt
@[https://xordataexchange.github.io/crypt/]
(in combination with with etcd or consul)

Key Mng.Serv.(KMS)
- Google Cloud KMS
- Amazon KMS
- Android Keysotre
- Apple iOS KeyChain
- ...?

Technology Radar

Trillian "Big"MerkleTree
Trillian is an implementation of the concepts described in the
Verifiable Data Structures white paper, which in turn is an extension and
generalisation of the ideas which underpin Certificate Transparency

BitLocker full disk encryption

RSA Conference

Lamport signatures
- quantum-proof cryptographic signatures
- Quantum Safe Ethereum proxy with
  Winternitz One-Time signatures
  @[https://github.com/tjade273/QEth]

Azure Sphere Pluton
@[https://azure.microsoft.com/en-us/services/azure-sphere/]
Azure Sphere is solution for creating highly secured,
connected MCU-powered devices.

- The Pluton security subsystem creates a hardware root of trust,
  stores private keys, and executes complex cryptographic operations.

Elliptic Curves
- ¿Safe?Curves:
@[http://safecurves.cr.yp.to/]
- Browser support
@[https://security.stackexchange.com/questions/31772/what-elliptic-curves-are-supported-by-browsers]


- TLS-RSA cert. with elliptic curve
@[https://crypto.stackexchange.com/questions/30503/tls-rsa-certificate-with-elliptic-curve-negotiation]

Comparisions of secp256r1-vs-secp256k1 Elliptic Curves:
@[https://crypto.stackexchange.com/questions/18965/is-secp256r1-more-secure-than-secp256k1]

Pairing primitives
@[https://www.math.uwaterloo.ca/~ajmeneze/publications/pairings.pdf]

RFC 8555
@[https://tools.ietf.org/html/rfc8555]
Published on 2015-05-22 according to
@[https://datatracker.ietf.org/doc/rfc8555/]
Public Key Infrastructure using X.509 (PKIX) certificates are used
for a number of purposes, the most significant of which is the
authentication of domain names.  Thus, certification authorities
(CAs) in the Web PKI are trusted to verify that an applicant for a
certificate legitimately represents the domain name(s) in the
certificate.  As of this writing, this verification is done through a
collection of ad hoc mechanisms.  This document describes a protocol
that a CA and an applicant can use to automate the process of
verification and certificate issuance.  The protocol also provides
facilities for other certificate management functions, such as
certificate revocation.

Key Shadowing
@[https://patents.google.com/patent/US9634836]