Java – Crypto : Presentation of Cryptology (concepts, types of keys symmetric, asymmetric, examples,…)

Hello,
Through several articles, I would like present the cryptographic mechanisms, types of keys, certificate, types of algorithms …etc:

• PRESENTATION : Concepts of Cryptography (concepts, types of keys symmetric/asymmetric, …)
• The principles of SSL
• The principles of Signature and Certificate
• The principles of Hardware Security Module HSM
• Encoding with base64, base64url, rfc-4648
• Encryption with Blowfish (Anonymization)
• Encryption with AES/CBC, AES/EBC (Encryption of files)
• Encryption with PBEWithMD5AndDES (Encryption of files)
• Encryption with RSA (asymmetric keys private and public)
• KeyStore, JCEKS, SecretKey, PrivateKey, PublicKey, Certificate
• Example, Use of SecretKey, PrivateKey, PublicKey, CSV file (CryptoTools, GenericObfuscationFile)

PRESENTATION : Concepts of Cryptography Java/Crypto : Presentation of Cryptology (concepts, types of keys symmetric/asymmetric, examples,…)
 
The cryptography provides tools to perform security functions such as confidentiality, integrity, authenticity and non-repudiation.
 
These tools are based on cryptographic mechanisms consisting of algorithms (called also primitive), operating modes (called also diagram) and protocols:

 
 
For the next posts, we must keep in the mind the following points and vocubulary:
 
The types of keys:

• symmetric type: the sender and the recipient have the same key (secret key).
  Examples: PBEWithMD5AndDES, AES/CBC/PKCS5Padding, Blowfish,…etc.
  
• asymmetric type: the sender and the recipient haven’t the same key i.e. there are a private key and a public key. Examples : RSA,…etc.
  

 
 
Certificate
The certificate, in addition to the public key, contains additional information, such as issuer, what it’s supposed to be used for, and any other type of metadata. Typically a certificate is itself signed with a private key, that verifies its authenticity. There are many command-line tools available for creating X.509 certificates, like the keytool distributed with the Sun JDK or openssl, ported to many platforms.
A self-signed certificate is that the issuer of the certificate is the subject of the certificate, i.e, you sign your own certificate with your own private key.
 
 
Different types of certificate
Electronic certificates meet standards that specify their content rigorously. The two formats most used today are:

• X.509 defined in the RFC 52802
• OpenPGP defined in the RFC 48803

The significant difference between these two formats is that an X.509 certificate can contain only one identifier, that identifier must contain many predefined fields, and can only be signed by a single CA.
An OpenPGP certificate can contain multiple identifiers, which allow for some flexibility on their content, and can be signed by several other OpenPGP certificates, which then builds trustworthy networks.
 
 
X.509 (https://en.wikipedia.org/wiki/X.509)
In cryptography, X.509 is an important standard for a public key infrastructure (PKI) to manage digital certificates and public-key encryption and a key part of the Transport Layer Security protocol used to secure web and email communication. An ITU-T standard, X.509 specifies formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.

In the X.509 system, an organization, who wants a signed certificate, requests one via a certificate signing request (CSR). To do this, they first generate a key pair, keeping the private key secret and using it to sign the CSR.
This contains information identifying the applicant and the applicant’s public key that is used to verify the signature of the CSR – and the Distinguished Name (DN), the fully qualified domain name that the certificate is for.
The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority. The certification authority issues a certificate binding a public key to a particular distinguished name. An organization’s trusted root certificates can be distributed to all employees so that they can use the company PKI system. Browsers such as Internet Explorer, Firefox, Opera, Safari and Chrome come with a predetermined set of root certificates pre-installed, so SSL certificates from larger vendors will work instantly; in effect the browsers’ developers determine which CAs are trusted third parties for the browsers’ users.
X.509 also includes standards for certificate revocation list (CRL) implementations, an often neglected aspect of PKI systems. The IETF-approved way of checking a certificate’s validity is the Online Certificate Status Protocol (OCSP). Firefox 3 enables OCSP checking by default along with versions of Windows including Vista and later.
 
 
Certificate chain
To obtain a certificate chain, a first certificate (A) is signed via the private key associated to another certificate (B). This second certificate (B) is also signed via the private key associated to a third certificate (C)… this process continues until the last certificate is a trusted root certificate used to sign the previous certificate. A trusted root certificate is signed by trusted root CA like VeriSign.

 
 
Confidentiality – Case of data transmission: ACTOR1 sends crypted data to ACTOR2

• ACTOR1 uses the public key of ACTOR2 in order to encrypt and send the data to ACTOR2,
• ACTOR2 uses its private key in order to decrypt the received data from ACTOR1,

 
 
Authentication – Case of signature: ACTOR1 signs a document

• ACTOR1 uses its private key in order to sign the document,
• ACTOR2 (recipient of this document) uses the public key of ACTOR1 in order to authenticate the document signed by ACTOR1,

Note: The sent document could be also encrypted.

 
 
A transformation is of the form:

• “algorithm/mode/padding”
• “algorithm”

(in the latter case, provider-specific default values for the mode and padding scheme are used).
For example, the following is a valid transformation:

Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

 
More definitions:
 
Encoding
Encoding is for maintaining data usability and can be reversed by employing the same algorithm that encoded the content, i.e. no key is used. The goal is not to keep information secret, but to transform data into another format using a scheme that is publicly available so that it can easily be reversed.
Examples: ASCII, Unicode, URL Encoding, Base64

 
Encryption
Encryption is for maintaining data confidentiality and requires the use of a key (kept secret) in order to return to plaintext. The goal is to ensure the data cannot be consumed by anyone other than the intended recipient(s). So encryption can reverse the transformation. It uses a key, which is kept secret, in conjunction with the plaintext and the algorithm, in order to perform the encryption operation.
Examples: AES, Blowfish, RSA

 
Hashing
Hashing is for validating the integrity of content by detecting all modification thereof via obvious changes to the hash output. Technically, hashing takes arbitrary input and produce a fixed-length string that has the following attributes:
1.The same input will always produce the same output.
2.Multiple disparate inputs should not produce the same output.
3.It should not be possible to go from the output to the input.
4.Any modification of a given input should result in drastic change to the hash.
Examples: SHA-1, SHA-3, MD5 (Now obsolete), etc.

 
Obfuscation
The purpose of obfuscation is to make something harder to understand, usually for the purposes of making it more difficult to attack or to copy.

It’s important to note that obfuscation is not a strong control (like properly employed encryption) but rather an obstacle. It, like encoding, can often be reversed by using the same technique that obfuscated it. Other times it is simply a manual process that takes time to work through.
Examples: JavaScript Obfuscator, ProGuard

 
 
Anonymization
Data anonymization is a type of information sanitization whose intent is privacy protection. It is the process of either encrypting or removing personally identifiable information from data sets, so that the people whom the data describe remain anonymous.

 
Encryption and Java:
 

With Java, security has many aspects:

• The language specifications have features to enhance code security
• The platform defines a model to manage the rights of an application
• JCA / JCE APIs allow the use of cryptographic technologies
• The JSSE API allows the use of the network through secure SSL or TLS protocols
• The JAAS API provides a service to manage user authentication and permissions

 
JCA / JCE ?
The Java Cryptography Architecture (JCA) API provides basic cryptographic capabilities to the Java platform. The Java Cryptography Extension (JCE) API is an extension of JCA that adds APIs for encryption and decryption, key generation, and message authentication with MAC-based algorithms. Originally, JCE was developed as an extension of the JDK 1.2. Before Java 1.4, JCE was broadcast separately. JCE is integrated with Java SE as of version 1.4. Since the JCE is provided with the JDK, both APIs may seem less distinct since JCE relies on JCA. JCE is based on a design principle similar to that of JCA: its implementation requires the use of an implementation of a supplier. The Sun / Oracle implementation provided by default with Java is named SunJCE (provider SunJCE).
 
The JCA API is contained in the java.security.* package and the JCE API is contained in the javax.crypto.* package.

Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction
Due to import control restrictions of some countries, the version of the JCE policy files that are bundled in the Java Runtime Environment, or JRE(TM), environment allow “strong” but limited cryptography to be used. So, JAVA/ORACLE provides “unlimited strength” policy files which contain no restrictions on cryptographic strengths : Unlimited Strength Java(TM) Cryptography Extension (JCE) Policy Files for the Java(TM) Platform, Standard Edition (Java SE) Runtime Environment downloadable on http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html. For Environment Java 7, this ZIP file does NOT contain any encryption functionality as all such functionality is contained within Oracle’s JRE 7. This bundles assumes that the JRE 7 has already been installed.

This ZIP file UnlimitedJCEPolicyJDK7.zip contains the following files to copy to …\Java\jdk1.7.0_79\jre\lib\security folder:

• local_policy.jar
• US_export_policy.jar
• README.txt

 
 
Resources:
https://danielmiessler.com/study/encoding-encryption-hashing-obfuscation/#gs.mlNnAIc
http://www.differencebetween.com/difference-between-stream-cipher-and-vs-block-cipher/

 
Best regards,

Huseyin OZVEREN