Dear Community,
like I felt the need of collecting terms and abbreviations and their meanings in the huge and complex area of security, I feel like I should share the list with you, as you might have the same need.
It is like:
-> Read ABC anywhere
-> forgot the meaning (again)
-> look it up (again)
-> luckily bookmarked this helpful blog post in the SAP Community...
Below list is obviously far from being complete or professional or official.
Nor are the links officially approved, so use them at your own risk.
At the end, it is just my personal list which I'm sharing with you.
The terms are loosely grouped - as of my feeling, so better use CTRL+F for finding your search term.
Please don't hesitate to contact me for improvements, suggestions and additions.
And a disclaimer: I'm not expert, please forgive if I'm not precise.
Quicklinks:
JWT
Cryptography
IAS/AMS
OIDC
OIDC
OpenID Connect:
A protocol.
Allows web applications (= relying parties) to authenticate users with an external server (= OpenID Connect Provider).
This server typically gets user information from an identity provider (IdP), which is a database of user credentials and attribute information.
OpenID Connect forwards to concrete IDP
OpenID Connect, 2014, is not the first standard for IdP, but the best (usability and simplicity), learned the lessons from past (SAML + OpenID)
Info at openid.net and spec at openid.net
RP
Relying Party: the client that requests an ID token
OP
OpenID Provider, OpenID Connect Provider:
Provides endpoints: authorization, token, UserInfo
OIDC tokens
Access token:
A string containing a unique secret token.
Access token has specific permissions and is used to get data from an API.
Expires soon, typically within 24 hours.
OAuth.
Access token only for oauth, not relevant for openid authentication request.
Required for UserInfo endpoint
Refresh token:
A string containing a unique secret token.
Refresh token enables its bearer to request and obtain new Access tokens.
These newly obtained access tokens have a subset of the permissions that the Refresh token has. The Refresh token never expires.
ID token:
Resembles the concept of an identity card, in a standard JWT format, signed by the OpenID Provider
requested via oauth protocol.
Response:
Base64-encoded JSON document.
The json document contains access token refresh token and ID token.
ID tokens are created and signed by OpenID Connect Providers (OP) and consumed, verified by web applications authenticating users.
The ID token contains information about how and when the user authenticated along with various attributes.
ID tokens are normally intended for sign-on, access tokens for calling protected APIs
Claims
user attributes. Properties about user,
e.g. email
https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
See here for registered OIDC claims:
https://openid.net/specs/openid-connect-core-1_0.html#IDToken
OIDC Libs
Node.js Lib: https://www.npmjs.com/package/openid-client
docu: https://github.com/panva/node-openid-client/blob/main/docs/README.md
OIDC links
OpenID spec: https://openid.net/connect/
Authentication flow:
https://infosec.mozilla.org/guidelines/iam/openid_connect.html#detailed-oidc-authentication-flow
https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
https://developers.onelogin.com/openid-connect/samples
https://codeburst.io/how-to-implement-openid-authentication-with-openid-client-and-passport-in-node-...
https://codeburst.io/openid-connect-client-by-example-76caf6dae55e
https://medium.com/@goranlisak/how-to-implement-openid-connect-authentication-flow-inside-of-an-ifra...
https://connect2id.com/learn/openid-connect
OIDC<->SAML: https://github.wdf.sap.corp/d035752/oidcnodejs/blob/master/theory.md
OIDC client impl guide: https://openid.net/specs/openid-connect-basic-1_0.html
SAML
SAML
Security Assertion Markup Language
Is a protocol (Authentication) used for SSO
Typically used for scenarios where users in big companies have to use multiple applications.
Instead of entering users/passwords for each application, they login only once, and the login is reused for each application.
Known as Single Sign-On (SSO) login standard.
We use SAML as well for Principal Propagation.
In this context, we talk as well about Identity Federation.
SAML is used in browser-based scenarios.
Entitiy
The involved systems are called “Entities”: Identity Provider and Service Provider (SP).
SP
Service Provider is also called Relying Party (relies on proper authentication by IdP)
When login is required, the user has to do the authentication request at IdP.
IDP
The user authentication is handled by a central Identity Provider
The IdP issues a little document which contains the user-info (identity) and which is passed to each application.
Identity Provider is also called Asserting Party.
The IdP creates a little xml document, which is the authentication response and contains the user’s identity.
Assertion
This little xml document is also called SAML Bearer Assertion (because it is carried around, from app to app) or just token.
The token is stored in the user’s browser session and is sent to each application the user wants to access.
It is signed with X509 certificate.
The receiving Service Provider is able to verify the signature, because a trust relationship has been established between IdP and SP.
To establish the trust relationship, SAML supports metadata documents on both sides (IdP and SP)
Metadata contain e.g. the info about endpoints used for redirects etc.
ACS
The SP metadata contains the Assertion Consumer Service URL (ACS Endpoint).
SAML assertions are sent to this endpoint.
Advantage
Security is handled centrally, applications don’t need to store uses and passwords, users don’t need to enter pwd for each app.
SAML is open standard and provides flexibility.
Disadvantage
The little xml document is quite big and causes network overhead.
Main focus is authentication.
Authorization capabilities are rather poor.
Difference to OAuth
SAML2 can be used for both authentication and (limited) authorization.
OAuth2 is an authorization framework. Authentication is not in scope.
However, OAuth2 can be enhanced (with openID) and used for SSO as well.
OAuth2 uses JWT tokens which are smaller than the xml-based SAML assertions.
Different terms for similar concepts
Service Provider (SAML) corresponds to Resource Server (OAuth).
Identity Provider (SAML) corresponds to “Authorization Server” (OAuth).
Client: browser (SAML) corresponds to (mostly) web app clients in OAuth.
SAML links
https://developers.onelogin.com/saml
https://stackoverflow.com/questions/26901368/saml-adfs-node-js-implementation-guide/36897549#3689754...
https://pages.github.tools.sap/kernelservices/tutorials/identity-service-saml-nodejs/ , http://www.passportjs.org/packages/passport-saml/
https://help.sap.com/viewer/6d6d63354d1242d185ab4830fc04feb1/Cloud/en-US/fe3102ad92d94baa955ffa06b86...
OAuth
OAuth 2.0:
A framework for obtaining access tokens for protected resources.
If a target resource is protected with OAuth, we cannot send a user password (like Basic Auth), but instead, we need to fetch a JWT token from the Authorization Server. This is done via an HTTP request and we need to authenticate with clientid/secret. The token is then sent as “Bearer” token to the protected resource.
The resource is accessed by an OAuth client on behalf of a user, as such, password is not handled by web app, which is more safe
For fetching an access token, there are several flows (can be extended).
Client Credentials flow
Used for app-to-app, no user required, fetch token with clientid/secret
Authorization Code flow
Typically used by user-facing web apps.
At BTP, the approuter takes care of executing this flow.
Requires active user login.
It involves sending a code to a previously registered redirect-endpoint, which makes the flow more secure
Resource Owner Password flow
Deprecated, because not safe
To avoid interactive user-login, the user-credentials are send in the request, together with clientid/secret.
Used for prototyping with technical users.
JWT Bearer flow
This grant type allows to fetch a new JWT token by sending an existing token.
Used in Token-_Exchange scenarios.
Spec - CloudFoundry UAA reference
Understanding Token Exchange blog series
PKCE
Proof Key for Code Exchange:
An extension to the Authorization Code Flow (OAuth) to be able to securely perform the OAuth exchange from public clients.
https://oauth.net/2/pkce/
https://www.oauth.com/oauth2-servers/pkce/
https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce
JWT
JWT
JSON Web Token
A piece of data
Encoded with Base64
Designed to be compact
JWT specification: rfc7519
Structure
- Header
- Payload (JSON)
- Signature
JOSE
Javasceript Object Signing and Encryption
Framework to provide a method to securely transfer claims between parties.
The JOSE framework provides a collection of specifications to serve this purpose
JWS
JSON Web Signing
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature
JWE
JSON Web Encryption
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption
JWK
JSON Web Key
A JSON data structure that represents a cryptographic key.
Format, e.g. for provider’s public keys (RSA) spec:
https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41
JWKS
JSON web key set.
Used to store public JSON web keys
JKU
JWK Set URL
A URI that points to location where public keys are stored.
JSON array of JSON objects with keys.
Jku is a claim contained in a JWT token
Claims
Properties contained in the payload of JWT token
A statement that a subject makes about itself.
Claims list (standard)
aud
Audience
The receiver for which the token was issued.
Typically the clientid of the credentials section in env
exp
Expiration Time
iat
Issued at
iss
Issuer
jti
JWT ID
Unique identifier of the token itself.
nbf
Not before
sub
The “Subject” of the client, it is the same as the client id
Claims list (common)
alg
Algorithm to verify the signature of the token
cty
Content Type
kid
The key that was used to generate the signature of the token
crit
Critical
typ
Token Type
Claims list (more)
acr
Authentication Context Class Reference
amr
Authentication Methods References
azp
Authorized party - the party to which the Token was issued.
The OAuth ClientID of this party.
Optional claim, same as aud.
cnf
Stands for “Confirmation”, this is a fingerprint of the client certificate that was used to fetch the JWT token. It is only present in the JWT, when mTLS is used.
x5t#S256 means that a fingerprint of a X.509 certificate (-> x5t) was created with SHA-256 algorithm (-> S256) See rfc7800 and rfc8705
ext_attr
This “external attributes” is a section that can be filled with custom data.
Even clients can add custom data here, that needs to be transferred to the receiver.
A typical example could be the good old abap_name, when user info is sent to backend.
authorities
List of permissions, like scopes.
scope
List of permissions, as defined in xs-security.json file, in case of XSUAA.
cid
cliend id
rev_sig
Revocation Signature, a hash which can be used to revoke a token, if supported by the server
zid
zone id, currently equal to tenant id (can be found on overview page of subaccount in BTP)
See here for registered and public claims:
https://www.rfc-editor.org/rfc/rfc7519#section-4.1
https://www.iana.org/assignments/jwt/jwt.xhtml
Cryptography / Certificates
Encoding
Transform some format. Is reversible without additional info, no secret/pwd required.
Make data readable in special but common way.
Sender has data in strange format, then encodes it with base64, which can be decoded by anybody.
This ensures that the strange format doesn’t break while it is transferred over network.
The encoding, like base64 (or ASCII, or URL encode), doesn’t contain strange characters which might get lost or broken.
As such, useful for binary data and similar, for systems that send data over net, better convert binary to text.
Encryption
Make secret data unreadable, for security reason. Pwd required to decrypt (key/secret).
Sender encrypts data with key -> recipient decrypts with key
Can be symmetric (secret key, e.g. AES) or asymmetric (public/private key, e.g. RSA).
You'd like a really intuitive example? See my blog post here.
My CPI Encryptor blog contains intuitive intro.
Symmetric Encryption
AKA secret key encryption
Sender encrypts data with a key.
Sender gives the key to the recipient
Sender sends encrypted data to recipient
Recipient decrypts the data with the (symmetric) key.
Symmetric encryption is faster than asymmetric.
Symmetric encryption can handle bigger sizes of data.
Supports block mode and stream mode.
Asymmetric Encryption
Recipient creates key pair (asymmetric)
Recipient sends his public key to sender.
Sender encrypts data with this public key.
Sender sends encrypted data to recipient.
Recipient decrypts the data with the corresponding private key (key must match).
Key Pair
Public key and private key must correspond together.
A message is encrypted with public key and decrypted with corresponding private key.
A message is signed with private key and verified with corresponding public key.
Openssl generates a private key which contains the public key as well, so the pubkey can be extracted (modulus and exponent) from generated private key with OpenSSL command.
The generated file is base64 encoded.
My memory hook for encryption:
I send messages from public post office, so use public key for send/encrypt.
I receive messages at home, so use private key to read/decrypt.
My memory hook for signing:
Reverse mode of encrypting
Secret Key
Typically, the key that is used in symmetric encryption is called "secret key".
Key Size
The size of the secret
The secret is used to encrypt the data
Longer key provide more security, but less performant
Security Token
Short pwd, valid only one-time or for a short period of time.
Usually bound to a special device e.g.phone or special hardware e.g. RSA SecurID keycards.
X.509
Standard defining the format of certificates.
The most common format for public key certificates
X.509 certificates are used in TLS/SSL, the basis for HTTPS
Certificate contains a public key and an identity and is signed by a CA (or self-signed)
Structure is expressed in Abstract Syntax Notation One (ASN.1).
Contains several elements, e.g. Subject and Issuer, both identified by DN
DN is unique, as such, the issuer of a certificate can be identified and proven to bo OK
Formats can be PEM, DER etc
CSR
Certificate Signing Request
Defined within PKCS #10, see spec
The PKCS#10 standard defines a binary format for encoding CSRs for use with X.509.
It is expressed in ASN.1.
A CSR may be represented as a Base64 encoded PKCS#10
In the PKI system, a signed certificate is requested via CSR to Certificate Authority.
CSR contains info identifying the applicant
Also contains the applicant's public key that is used to verify the signature of the CSR -
Contains the Distinguished Name (DN) that the certificate is for.
Result: CA issues a cert binding a public key to a particular distinguished name.
A CSR can be generated with OpenSSL or tools in the internet.
CRL
Certificate Revocation List
If certificate is not safe, e.g. private key was revealed, then it can be revoked and added to this list which is publicly available.
OCSP
Online Certificate Status Protocol
Similar like CRL, but here the certificate is sent to a
CA
Certification Authority
Certificate
A digital certificate is used to prove trustworthiness of e.g. a server and a client.
A certificate is signed by a trustworthy parent certificate, which itself is signed by root CA.
In order to be signed, a CSR is generated and sent to CA.
Certificate contains public key (modulus and exponent) and fingerprint, bags, attributes, header data.
With other words:
A certificate is a public key that is signed, therefore its identity is proven and trustworthy.
See spec
In a chain, the first cert is called leaf, it corresponds to the user or client. Below comes one or more intermediate certificate, the last one is the root, corresponding to the CA.
Certificate Types:
DVC: Domain Validated Certificate
EVC: Extended validation Certificate
Both are commercially issued certificates, the difference is in the validation:
EVC is more expensive, more secure, required for sensitive websites, banking
Certificate Encoding:
DER: binary files
PEM: ASCII files, base64 encoded
File extensions: .cer, .crt, .der
usually in binary DER form, but Base64-encoded certificates are common (see .pem)
CBA
Certificate Based Authentication
A certificate proves that I'm the owner of the corresponding private key.
Authentication process:
I take my private key and sign a little random text
I send my certificate and that little text (nonce) to the server
Server verifies the nonce with the public key which is contained in the certificate
This verifies that I’m the owner of the private key that belongs to the certificate
As such, I am the one that is stated on the certificate.
Of course, the server also checks if the certificate itself is valid.
Advantage:
Browser can login to various system without user interaction
Private key is more safe than a password, as it cannot be remembered or phished
Disadvantage:
Private key must be stored securely
Certificates must be requested and renewed
Certificate Content
DN = Distinguished name, comprises of CN+OU+L etc
SAN = Subject Alternative Name
CN = Common Name, e.g. domain name of the website
OU = Organizational Unit
L = Locality
O = Organization
C = Country
Subject: Field in certificate which is uniquely identified by its DN
Issuer: Field in cert, uniquely identified by DN, parent cert which signed the actual cert
PEM
Originally Privacy Enhanced Mail.
Most common format for X. 509 certificates ( etc.)
A text file using Base64 ASCII encoding for the (binary) DER content
PEM describes the encoding of the ASN.1 Distinguished Encoding Rules in base64.
Defines plain-text headers and footers
(e.g. -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----)
PEM is a container format for digital certificates (chain) and keys.
A file extension of a file that contains a bunch of certificate files.
File extensions can be: .pem .cer .crt .cert .key
DER
Distinguished Encoding Rules
A restricted variant of BER
DER is the same thing as BER with all but one sender's options removed.
DER is a subset of BER providing for exactly one way to encode an ASN.1 value.
DER is intended for situations when a unique encoding is needed, such as in cryptography,
For example, in BER a Boolean value of true can be encoded as any of 255 non-zero byte values, while in DER there is one way to encode a boolean value of true.
DER encoding constraints example: Length encoding must use the definite form
DER is widely used for digital certificates such as X.509.
Typically:
A binary encoding for X.509 certificates and private keys.
No ---BEGIN statements
Can store only one certificate, no chain, no key
Common in java
File extensions .der .cer
Content looks like this:
310b 3009 0603 5504 0613 0255 5331 0e30
BER
Basic Encoding Rules
CER
Canonical Encoding Rules
HSM
Hardware Security Module,
A hardware-based security device that generates, stores, and protects cryptographic keys
PSE
Import the certificate of the authorisation server into a Personal Security Environment (PSE) also known as a Certificate Collection.
PBE
Password Based Encryption
PKI
Public key infrastructure. Helps to check if certificate and public key belong together. Requires another cert which is in the chain.
The certificate chain is hierarchical structure where the parent signs many child-certificates.
PKIX
Public key infrastructure X509.
Web of Trust
Other than the hierarchical PKI, this is a flat network of trust.
Each partner confirms the trust of the other partner's public key.
PKCS#1
Example:
-----BEGIN RSA PRIVATE KEY-----
Compared to PKCS8 unencrypted:
-----BEGIN PRIVATE KEY-----
and PKCS8 encrypted:
-----BEGIN ENCRYPTED PRIVATE KEY-----
PKCS#7
Or PKCS7: Public Key Cryptography Standard number 7
Spec: https://tools.ietf.org/html/rfc5652
Foundation for S/MIME
Evolved to CMS standard (see my blog posts)
Standard for signing or encrypting ("enveloping") data.
Since the certificate is needed to verify signed data, it is possible to include them in the SignedData structure.
File extension: .p7b .p7c
A .p7c file is a degenerated SignedData structure, without any data to sign
PKCS#8
Example:
-----BEGIN PRIVATE KEY-----
PKCS#12
Or PKCS12: Public Key Cryptography Standard number 12
Spec: https://tools.ietf.org/html/rfc7292
evolved from the personal information exchange (PFX) standard
Used to exchange public and private objects in a single file
Binary format
Can be password-protected
Used as container to store certificate, chain, key
Used to export/import
File extension: .pfx .p12
CMS
Cryptographic Message Syntax
MCS is the successor of PKCS #7, after it was handed over to IETF in 1999
The standard describes how to send secure messages.
The standard contains descriptions for encrypting, digitally signing and others
It describes how to e.g. sign and encrypt, and how to store the signature, encrypted hash, certificate, algorithm info in the message, which is like a package.
A CMS-based message contains all artifacts and information that is required by the receiver to decrypt and read a message.
As such, sender & receiver can be humans or computer systems, like SAP systems.
SAP supports CMS in SAP Cloud Integration in an easy way (see my blog posts)
MIME
Multipurpose Internet Mail Extensions
Internet Standard, extends the format of a mail message, should allow that email contain not only ASCII text, but also other character sets.
Furthermore attachments of e.g. audio, video, images, etc
S/MIME
Secure MIME
Protocol for secure emails
Uses CMS in case of encryption, digital signature and so on
.p7m
File extension
Encrypted email message that contains the contents and attachments of a sensitive email.
.p7s
File extension
An email message that includes a digital signature.
It can be used for sending secure emails that can only be viewed by the intended recipient.
P7S files verify that the email is from who it claims to be from and that the email has not been modified in transit.
JKS
Java Key Store
Used to store certificates or key pairs in binary format.
Keystore is a binary file with file extension .jks
JKS is used in Java environments, alternatively p12 is used and more flexible
Java Key Stores are created with the keytool command line tool, installed together with Java JDK and can be copied and used standalone
Hash Function
Used to create a hash value out of a message (or any other data).
The resulting hash value has fix length, whereas the origin data is of arbitrary length.
Used to ensure "integrity" of data.
Note: does not ensure "authentication" of hashed data .
E.g.
We have a text file.
We use hash function to create a hash value, based on the text file.
We send the file to a friend.
We also send the hash to the friend.
The friend creates his own hash value, based on the text file.
The friend compares both hashes: they must match.
If not, then the text file has been modified by a hacker
CHF
Cryptographic Hash Function
Same as hash function, but more secure.
It should not be possible to take the hash value and calculate the original value (preimage).
It should not happen that hashing 2 different data result in the same hash value (collision).
Hash
Or: hash value
Or: hash code
Or: (message) digest
Or: Fingerprint
Or: checksum
Typically used as synonyms in the world of cryptography.
Result of applying a hash function to a document
Hash Collision
Little change in the original input text (or whatever) results in a completely different hash value (digest)
Salt
Some extra bits that are added to a hash value, to make it even more secure.
Hash Algorithm
A math formula, used by hash functions
E.g. MD5, SHA1 etc
ESS
Enhanced Security Services for S/MIME
Specified in rfrc 2634 and 5035
Describes four optional security service extensions for S/MIME:
- signed receipts
- security labels
- secure mailing lists
- signing certificates
Example: Triple Wrapping
A message is signed, then encrypted, then signed again.
Thus, have signed attributes bound to the encrypted body.
DSIG, Digital Signature
Similar like Hash Value, but is created with private key and verified with public key.
As such, ensures "integrity" and "authentication".
A signature is a piece of unreadable characters sent in addition to the message itself.
Example:
I send you a message
you sign it (privkey) and send to me.
I can now verify if you signed my original message, using your public key.
My CPI Signer blog contains some intuitive intro.
eSignature
Electronic Signature
A signature is used to proof the identity of the signer. And also his intention.
Usually done with handwriting, but in modern times also done electronically.
Electronic Signature is the broad term, a specific type of eSignature is the Digital Signature.
SES stands for Simple Electronic Signature.
AES or AdEs stands for Advanced Electronic Signature and is a digital signature
QES stands for Qualified Electronic Signature and is a digital signature
AdES / AES
Advanced electronic signature
An electronic signature that has met the requirements of European Regulation (eIDAS-regulation) on electronic identification and trust services for electronic transactions.
Requirements, e.g.
The signer can be identified and linked to the signature
It ensures that the signed data is not modified
Can be invalidated, if signed data has changed
CAdES
CMS Advanced Electronic Signatures
A set of extensions to CMS standard.
More concrete: to the signing part of the CMS.
These extensions make the CMS suitable for AdES (Advanced Electronic Signatures)
While CMS is generic specification, the AdES extension contains precise specifications for the signature.
This makes it compliant with European Regulations for electronic signatures (eIDAS)
As a consequence, a CAsES-Signature has the same legal value like a handwritten signature (in Europe)
One of the CAdES-profiles (the simplest one) is CAdES-B: Basic Electronic Signature (BES)
It fulfils the minimum requirements for trusting that an electronic signature properly identifies the signer.
wiki
Cipher
The algorithm used for encryption/decryption, like a math formula
Typically, a key is used. Larger keys result in higher security, but lower performance.
In such cases. a key must be selected before using a cipher to encrypt a message
Block ciphers: encrypt block of data of fixed size
Stream ciphers: encrypt continuous streams of data
Examples for ciphers:
AES can be 128, 192, 256 bit, faster than Triple-DES
BF Blowfish, since 1993, symmetric, block cipher,
block size 64 bits, key size variable, usually 128 bits
CAST based on CAST design procedure
DES Data Encryption Standard (1970s), (64bit) symmetric, replaced by Triple-DES, then AES
TDES == Triple DES == 3DES == DESede: use DES algorithm 3 times
DESX DES-X, Extended DES, since 1984, enhancement to DES, increasing the key size to 184 bits
GOST Russian government standard symmetric key block cipher (64 bit), since 1989
IDEA International Data Encryption Algorithm
MD5 Message Digest Method 5
RC2 128 bit, designed by Ron Rives, RC = Rons Code or Rivest Cipher
RC4 can be 40, 64, 128 bit
RC5 RC5 cipher
RSA
Cipher Suite
List of supported algorithms, used for encryption.
Typically exchanged during TLS handshake
Ciphertext
A plaintext message is encrypted to ciphertext message.
Stream Cipher
Stream mode: encryption is done bit per bit
Considered weak form of encryption
Examples:
A5/1: since 1987, based on A5 security protocol, weaknesses detected
RC4: since 1987, Rivest Cipher 4, aka ARC4 or ARCFOUR (Alleged RC4), vulnerabilities found
Block Cipher
Encryption is done block by block
E.g. DES uses 64-bit blocks, AES uses 128-bit-blocks (among others)
Examples:
AES Advanced Encryption Standard
Blowfish
DES Data Encryption Standard
Twofish related to earlier Blowfish, block size 128 bits
Camellia block size 128 bits, named by Japanese flower
CAST
GOST
IDEA International Data Encryption Algorithm
RC2
Block
A block is a group of bits with fix length.
MD2
Stands for Message Digest Algorithm No 2 and was designed by Ronald Rivest in 1989, for 8-bit computers.
Size of hash value: 128 bits (16 bytes).
Considered weak
MD4
Message Digest Algorithm No 4, designed by Ronald Rivest in 1990
Size of hash value: 128 bits (16 bytes).
Considered unsafe
MD5
Message Digest Algorithm No 5, since 1991
Designed by Ronald Rivest in 1991 to replace MD4.
Size of hash value: 128 bits (16 bytes).
The hash is represented as 32-digit hexadecimal digits.
Considered unsafe
SHA
Secure Hash Algorithm which is a family of hash functions
published by NIST (National Institute of Standards and Technology).
The family consists of:
SHA: original version, 160 bit, since 1993, unsafe.
SHA-1: 160 bit, replaced the original version, but removed at 2010.
SHA-2: since 2001, consists of
SHA-256 with 256 bits
SHA-512 with 512 bits
In addition: SHA-224 and SHA-384 and SHA-512/224 and SHA-512/256
SHA-3: same properties as SHA-2 but internally the hash is computed differently. Since 2015.
RIPEMD
Stands for RACE Integrity Primitives Evaluation Message Digest.
Family of cryptographic hash functions since 1996.
RIPEMD-160 has not been broken.
Size of hash value: 160 bits (20 bytes).
The family consists of:
RIPEMD: output hash value size: 128 bits, weak
RIPEMD-128: output hash value size: 128 bits, weak
RIPEMD-160: output hash value size: 160 bits, most common
RIPEMD-256: output hash value size: 256 bits, similar security level
RIPEMD-320: output hash value size: 320 bits, similar security level
MGF1
MGF stands for Mask Generation Function.
It is almost the same as cryptographic hash function, with following difference:
CHF generates values of fix size.
MGF generates values of fix size, but it can be configured.
MGF has one implementation called MGF1
AES
Advanced Encryption Standard e.g. 128 bit (or 192 and 256)
A block cipher that encrypts/decrypts blocks of bits.
(unlike stream cipher, which encrypts bits one at a time)
Most commonly used symmetric encryption algorithm.
CBC
Cipher block chaining
HMAC
Hash-based Message Authentication Code
Used to verify the message's impartiality and validity
ECDHE
Elliptic Curve Diffie Hellman Ephemeral
GCM
Galois Counter Mode
Used when the data is larger than the used algorithm handles.
So multiple blocks are created (e.g. by AES) and they are managed by GCM
Operation Mode
Some algorithms (Block Ciphers) do their encryption work on blocks.
Usually, the data is larger than the blocks.
As such, the cipher has to be applied repeatedly.
A “block cipher mode of operation” describes how this is done.
Specifications in FIPS, NIST
Examples for modes of operation:
ECB Electronic Codebook
CBC Cipher block Chaining
CTR Counter
CFB Cipher Feedback
OFB Output Feedback
Padding
Before encrypting e.g. a message, some arbitrary data is added to beginning or end of the message.
This is done to avoid that a hacker could guess typical message-ending phrases, which would facilitate the hacking.
There are multiple practices for padding.
In symmetric encryption, the encryption can be done in blocks. So padding is used to fill up the last block.
If not done in blocks, but in streaming mode, then padding is not required.
In asymmetric encryption, a padding scheme is used to prepare the message for encryption.
E.g. OAEP, PSS
PCKS5 Padding and PCKS7 Padding is done in whole bytes.
PKCS#1 version 1.5 defines 2 different padding schemes for encryption and signature:
RSAES-PKCS1-v1.5: here ES stands for Encryption Scheme
RSASSA-PKCS!-v1.5: here SSA stands for Signature Scheme with Appendix.
Newer:
RSAES-OAEP: here Optimal Asymmetric Encryption Padding
RSASSA-PSS: here Probabilistic Signature Scheme
RSA
Rivest Shamir Adleman (three academics who first described this system in 1977)
One of the most widely adopted asymmetric algorithms, commonly used in PKI cryptosystems.
RSA algorithm used to generate key-pair.
Key sizes are larger than e.g. AES. RSA supports 1024, 2048, 4056
Raw RSA or textbook RSA mean RSA without padding scheme.
Raw RSA is not safe.
PKCS#1: RSA Cryptography Specification: RFC3447
RSA-OAEP
Optimal Asymmetric Encryption Padding
Alternative for e.g. RSA PKCS#1 v1.5
DSA
Digital Signature Algorithm, published by NIST in 1991
Asymmetric algorithm
Designed and used for digital signature and verification (faster than RSA)
Key size smaller than RSA
Not secure enough anymore
ECDSA
Elliptic Curve Digital Signature Algorithm.
Variant and successor of DSA, uses ECC (Elliptic Curve Cryptography).
Asymmetric algorithm
Used for digital signature and verification
Faster than RSA, uses shorter keys, suitable for small devices
ECC
Elliptic Curve Cryptography
Asymmetric algorithm
MAC
Message Authentication Code
AKA "keyed hash"
Basically, a hash function with added authentication via secret key
The (MA-)Code itself stands for the authentication code, or secret key, or tag. MAC is comparable to "Hash Function" and "Digital signature".
CHF ensures Integrity
MAC ensures Integrity and Authentication, uses symmetric key
DSIG ensures Integrity and Authentication and non-repudiation, uses asymmetric keypair
Non-repudiation: ensuring that the origin cannot be modified
Examples for MAC: HMAC, UMAC, GMAC, NMAC, CMAC, SHA1-HMAC, MD5-HMAC, CBC-MAC
Examples for CHF: SHA1 (compromised), SHA256, MD5 (compromised), SHA2, SHA3, BLAKE2
SSL
Secure Sockets Layer
TLS
Transport Layer Security
Successor of SSL
mTLS
mutual Transport Layer Security, mutual TLS
Process whereby, in addition to the normal TLS server authentication with a certificate, a client presents its X.509 certificate and proves possession of the corresponding private key to a server
Both server and client present their cert during TLS handshake
OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
on top of normal oauth flow, enhanced security, utilizing client-certificate-based mTLS
Spec: https://tools.ietf.org/html/rfc8705
https://en.wikipedia.org/wiki/Mutual_authentication
Example in Node.js:
https://cloud.google.com/dialogflow/es/docs/fulfillment-mtls?hl=de
PMS
Pre-master secret.
Some random bits that are encrypted with pubkey and sent to partner.
Based on PMS, a master secret and “session key” can be generated.
This one is used for symmetric encryption, as both partners have generated the same.
Session key can be based e.g. on AES128
Octet String
Octet stands for 8 bits forming a byte.
Putting these bytes into a sequence will form an Octet String.
Cryptographic Primitive
This is like a very basic functionality, which is used to build another functionality on top of it
E.g. a generic low-level algorithm, which is to build higher-level cryptographic algorithms.
Examples:
Hash function, symmetric key encryption, public-key encryption, digital signature, random generation
XFCC
X-Forwarded-Client-Cert, header, used to pass client certificate, in case of mTLS
DACL
Discretionary Access Control List and ACEs access entries .
Control Characters
exmples:
CR, LF,
EOT End of Tarnsmission
ETX End of Text
When viewing binary document with notepad++, don’t miss these explanations.
Useful tools
Decode Certificate
https://www.sslchecker.com/certdecoder
Generate Certificate
https://certificatetools.com/
Decode CSR:
https://certlogik.com/decoder/
https://redkestrel.co.uk/products/decoder/
Decode .p12
https://www.sslshopper.com/ssl-converter.html
extract p12 file to pem, whole file, not filtering key etc
https://www.sslshopper.com/certificate-decoder.html
Decode, convert:
https://www.httpcs.com/en/ssl-converter
Decode id_token and other:
https://oauth.tools/
Base 64:
https://www.base64decode.org/
Node.js Crypto API (native)
https://nodejs.org/api/crypto.html
AND of course: Openssl
main entry: https://www.openssl.org/docs/manmaster/man1
OpenSSL
Set of libraries that implement several standards
Set of utilities for command line.
IAS
IAS
Identity Authentication Service
Correct full name:SAP Cloud Identity Services - Identity Authentication
SAP Help:
SAP Cloud Identity Services - Identity Authentication
SAP Help landing page:
https://help.sap.com/viewer/product/IDENTITY_AUTHENTICATION
Identity service: JSON param docu
Video: Why IAS
IAS SAP Community
https://community.sap.com/topics/cloud-identity-services/identity-authentication
IAS SAP Community Parent
https://community.sap.com/topics/cloud-identity-services
Discovery Center
https://discovery-center.cloud.sap/protected/index.html#/serviceCatalog/identity-authentication
IPS
Identity Provisioning Service
Full name: SAP Cloud Identity Services - Identity Provisioning
The IPS server is used to copy users from a source system to a target, which can be scheduled to run e.g. on nightly basis.
For instance: “Please, each night do provision the users of Success Factors system to my IAS which is connected to my BTP account”.
This basic functionality is enriched with a ton of configuration options, e.g. mapping of user attributes of source to match the target system.
Furthermore, the IPS is intelligent enough to provision only the deltas of changed users, even if source system doesn’t support deltas.
SAP Help landing page: https://help.sap.com/docs/IDENTITY_PROVISIONING
IPS part of the SAP Cloud Identity Services offering, which includes:
Identity Authentication, Identity Provisioning, Identity Directory and Authorization Management services.
Authorization / AMS
XACML
eXtensible Access Control Markup Language
Authorization model is based on xacml
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
OPA
Open Policy Agent
https://www.openpolicyagent.org/
Open source policy decision engine which runs as a server next to the application (side car pattern)
DCL
Data Control Language
File extension: *.dcl
ADC
Authorization Decision Controller, the Policy Engine
PIP
Policy Information Point
PAP
Policy Administration Point, centralized
PRP
Policy Retrieval Point, centralized
PDP
Policy Decision Point, decentralized
ABP
Authorization Bundle Provider
ADC
Authorization Decision Controller
Is a OPA server and its deployment is done with CF multiple buildpack
CSL
Container Security Library
https://github.com/SAP/cloud-security-xsuaa-integration/
Other
IANA
Internet Assigned Numbers Authority
IAM
Identity- and Access-Management
CIAM
Customer Identity and Access Management
FIdM
Federated Identity Management
SCI
SAP Cloud Identity
SCIM
System for Cross-domain Identity Management
Standard for automating the exchange of user identity information between identity domains, or IT systems
A RESTful API for all necessary user management operations, managing resources (users, groups and custom schemas)
SCIM is used as communication protocol for User Role Assignment by IPS
SCIM Aims to simplify user provisioning and management in the cloud by defining two standards
A canonical user schema
A standardized schema and API for querying and managing user identities (attributes, etc.)
https://api.sap.com/api/IdDS_SCIM/overview
Spec: https://www.rfc-editor.org/rfc/rfc7644
SSTC
OASIS Security Services Technical Committee
SSO
Single Sign-On
SLO
Single Log-Out
PII
Personally identifiable information
Nonce
Number-only-used-once validation.
Service Broker
OSB
Open Service Broker API
https://github.com/openservicebrokerapi/servicebroker/
SBF
Service Broker Framework
Other
NIST
National Institute of Standards and Technology
ENISA
European Union Agency for Network and Information Security: https://www.enisa.europa.eu
ETSI
European Telecommunications Standards Institute
Standardization organization in the field of information and communications
LDAP
Lightweight Directory Access Protocol
An application protocol for distributed directory information services
A common use of LDAP is to provide a central place to store usernames and passwords.
This allows many different applications and services to connect to the LDAP server to validate users.
Other application layer protocols: FTP, HTTP, MQTT, TLS/SSL, SSH, Telnet, SMPT
ASN.1
Abstract Syntax Notation One
Standard interface description language for defining data structures that can be serialized and deserialized in a cross-platform way.
Commonly used in telecommunications, computer networking, cryptography.
Protocol developers define data structures in ASN.1 modules (a section of a broader document)
Encoding rules specify how to represent a data structure as a series of bytes (e.g. BER, CER, DER)
ASN.1 data is often binary
Encoded format is often PEM.
RFC
Request for Comments
Typically, it is a document containing a specification.
Usually created by international volunteers and maintained by IETF, has gone through several review processes.
After agreement, a number is assigned and it is published (and further maintained) via the rfc-editor
This is why links typically point a rfc-editor URL.
X.690
A standard specifying several ASN.1 encoding formats: BER, CER, DER
TOTP
Time-based One-time Password
Used for 2-factor authentication
- SAP Managed Tags:
4 Comments
