(SOA-)Security-Basics - part 5

(SOA-)Security-Basics - part 5

X.509 certificates

Cryptography

Identity? Digital ID? -> X.509 certificates

A X.509 certificate is just a digital ID. With that digital ID it can be decided, if the party showing this ID is who he claims to be.

[Example: https://www.google.com/]

X.509

Who does guarantee that?

The trust center!

Now, how does this work?

During the creation of a SSL connection or when a signature is verified, a certificate is transferred. This certificate states, that it is the server / communication partner of your trust. To verify that, the transferred certificate is read, its validity is tested and the publisher is determined. After that the validity of the publisher certificate is determined and then again the publisher. This will continue until the RootCA is reached. The RootCA certificate and all intermediate certificates have to be located in a trust store on the system, which conducts the check (be installed). Those certificates are trusted in principle.

X.509

- public key of the communication partner
- application of key (incl. "critical flags")
- e.g. CA, for S/MIME, SSL /key change, digital signature of documents
- date information of the validity
- used algorithms
- serial number
- reference to black lists OCSP responder
- reference to the publisher
- more OIDs
- 1.2.840.113533.7.65.0 - certificate extension for entrust version
- 1.2.840.113533.7.65 - Secure Networks Certificate Extensions
- 1.2.840.113533.7 - Entrust Technologies
- 1.2.840.113533 - Nortel Networks
- 1.2.840 - USA
- 1.2 - ISO member body
- 1 - ISO assigned OIDs

(SOA-)Security-Basics - part 4

Here comes part 4. Today we'll talk about certificates and PKI

X.509 Zertifikate / Public key infrastructure (PKI)

Trustcenter (TC) / RootCA / PKI

A trust center is a company, which issues "digital identities". This happens by letting a "trust tree" grow. The root is the so-called RootCA (CA = Certification Authority). It consists technically of a private key and the corresponding public key (often RSA). This combination is generated by the trust center itself (SelfSigned Certificate). This RootCA certificate must be trusted unconditionally, because all identities which are issued by the trust center are backtracked to this root. For the trust centers it is most important to keep their private key secret. Otherwise the trust center cannot be "trusted" anymore (Examples: Commodo, DigiNotar)

Public key infrastructure (PKI)

On basis of this RootCA, so-called intermediate CAs (Certification Authorities) are created. These are usually used for special purposes. They issue digital identities which are only suited for special areas (SSL, S/MIME, digital signature)

Part 5 will follow next week...

(SOA-)Security-Basics - part 3

"digital signature, certificates and digital identities"
This is the third part.

Private keys, public keys and the man in the middle

Introducing Alice, Bob and...

Alice sends a message to Bob and adds the hash value to this message. To ensure integrity Bob creates a hash value from the message and compares his hash value with the one that's included in the message. If the two values are identical, Bob knows that the message was not changed on its way!

BUT can Bob really be sure about that?

The man in the middle

Mallory, who is a crypto-villain, puts himself between Alice and Bob and captures the message! He then creates his own new message, hashes it and sends it to Bob. Bob again creates his own hash value and compares it. The result will be fine. Bob will not realize, that this is not Alices message! Hashing is good for integrity, but does not protect against an "man in the middle"-attack.

So what to do?

Very private but even so public

To solve this problem asymmetric cryptography is used. To encrypt something you need a key. In this case even two! A private key and a public key. Those two keys correspond mathematically in the following way:

- What is encrypted with the public key, can only be decrypted with the private key (but this is not interessting  for signatures)
- Important: What is encrypted with the private key, can only be decrypted with the public key

As the name indicates, the private key belongs to one person or institution. It is kept secret and nobody knows it, but the owner. The public key is sent to all communication partners.

Alice and Bob again...

Alice again sends a message to Bob. But this time they use asymmetric cryptography and hashing:

This time mallory cannot manipulate the message because if he would, the comparison would lead to another hash value. To sign the message again, he would need the private key of Alice. The second message from Alice to Bob is protected by a digital signature.

1. The integrity is guaranteed (hashing)
2. The author of the message is ensured (public / private encoding

Part 4 will follow...

(SOA-)Security-Basics - part 2

Here comes part 2 of "digital signature, certificates and digital identities". This is about hashing.

Hashing works, but only in one direction

Cryptographic hashing means, creating a checksum out of plain text. This checksum has to offer the following attributes:

1. The method is irreversible, which means, that you cannot calculate the plain text from the checksum
2. Different plain texts may not create the same hash value (the method must be collison-free)

Hashing - an example

There is the plain text "Hello World". This plain text is now hashed with the algorithm SHA1 and encoded with BASE64 for readability:

SHA1(Hello world) = pTVD5kns67A2N4yRuZ3vROStrxM=

Because the method has to be collision-free another plain text would create another hash value.
SHA1(Hello WorlD) = IYE/IEl7riYyhCez2P3l4xn9qrE=

The irreversibility is also ensured:
SHA1(Hello world) creates: = pTVD5kns67A2N4yRuZ3vROStrxM=, but
SHA1(Hello mars, how is the weather today on the red planet?) creates: = ZAmG0snPZ5zWTWdcwYCvJdZeApY=,
which also is a 28 character hash value encoded in Base64.

So what is the advantage of hashing?

- From a plain text an ambiguous checksum is created
- Every manipulation on the plain text causes another hash value to be created

==>
Thus, for every transmission of a message, its integrity is secured!


Part 3 will follow...

(SOA-)Security-Basics

My MT AG colleage Jan Quack just held a presentation about SOA-Security-Basics: digital signature, certificates and digital identities. I will publish parts of that here in the next weeks. I think this makes a good introduction into the world of signatures and certificates. It has some really nice examples, too ;-).

What is a digital signature?

A digital signature is a value which is computed with the help of cryptographic methods. It is applied with electronic documents and messages. This value allows to secure 2 different things:

1. The integrity of the message: Was the message altered on its way from the sender to the receiver?

2. The authorship of the message: Who composed the message?

... and how does this work?

Digital signature is based on two cryptographic methods, which are combined with one another:

1. Hashing

2. Asymmetric encoding

Part 2 will follow next week...