Static Key Cipher Vs Perfect Forward Secrecy

In cryptography, symmetric encryption, there are 2 ways to handle the session key. One is static key cipher, and another is Perfect Forward Secrecy (or simply Forward Secrecy).

Forward secrecy, is a feature key management that ensures session key will not be compromised if the long-term secrets (private signing key) used in the session key exchange are compromised. This means by compromise a single session key, it will not affect any data other than that exchanged in the specific session protected by the key.

Thus, FS can protects past sessions against future compromises of keys. But static key cipher is the other way. By using static key cipher, compromise of single session key (in the future) will lead to compromise of all the past encrypted session.

During the cipher suite negotiation, the client sends a handshake message with a list of cipher suites it will accept.  The server chooses from the list and sends a handshake message back indicating which cipher suite it will accept.  Although the client may order the list with the strongest cipher suites listed first, the server may choose any of the cipher suites proposed by the client.  (The client may even send those cipher suite with weakness to server) Therefore there is no guarantee that the negotiation will settle on the strongest suite in common.  If no cipher suites are in common the connection is aborted. 

Cipher suites using ephemeral DH and ephemeral ECDH (i.e., those with DHE or ECDHE in the mnemonic) provide perfect forward secrecy, ensuring long-term confidentiality of the session. 

Note that by restricting to TLS 1.2 cipher suite doesn't guarantee forward secrecy is always been used. For example, below are a list of TLS 1.2 approved ciphers, and those highlighted are still using static key cipher.

•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
•     Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
•     Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
•     Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
•     Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
•     Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
•     Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
•     Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

Note that FS is designed to prevent the compromise of a long-term secret key from affecting the confidentiality of past conversations. But, FS cannot defend against a successful cryptanalysis of the underlying ciphers being used. This is because, FS only protects keys (not the ciphers). If a cryptanalysis found a way to decrypt an encrypted message without the key, then FS cannot help here.

Mastering Burp Suite Pro

Just completed the training Aug (27~29) on Mastering Burp Suite Pro: 100% Hands-on. 

This is one of the HITB Technical training series by Nicholas Gregoire, one of the best Burp Suite Pro subject matter expert (SME) in the world.

Day 1

• Introduction to Burp: GUI, tools, audit workflow, inline help, …
• Proxy module: scope, filters, sorting, …
• Repeater module: exploitation of the D-Link DIR-100 backdoor, efficiency tips, …
• Intruder module: covering every attack type and most payload types

Day 2

• Advanced Proxy module: live modifications, interception and manual analysis, …
• Sequencer module: token analysis
• Advanced Intruder module: reusing configuration options, non default columns, …
• Auth module: horizontal and vertical privileges escalation

Day 3

• Macros and sessions module: transparent management of anti-CSRF tokens and short sessions
•  Extensions module: catalog of public extensions, developing your own, REST API, …
• Recently added tools: Collaborator, ClickBandit, Infiltrator

Why Simplify Cybersecurity?

Everything should start with WHY.

This is a series of simplify security posts, and let's start with WHY.  ;)

The reason is simple.

• Complexity is the enemy of Cybersecurity, particularly as the cyber threat environment grows more sophisticated nowadays.
• Thus, we should always look at reducing the number of tools, and fully embracing automation based on a fewer vendors.
•  By focusing on simplicity, we, as business leaders and cybersecurity professionals, can reduce risk and improve efficiencies.

 Next, I'll share more about what Simplify Cybersecurity is.

IoT/Embedded Device Hacking Training

Just finished attending the IoT/Embedded Device Hacking 5-day Training (Dec 18~22).

This training course is designed to help people working in the information security industry to learn basic knowledge needed to hack and reverse-engineer embedded system. The training covers embedded device hacking with UART/JTAG, dumping/parsing/extracting/analyzing firmware image, modifying firmware, detecting/analyzing embedded malware, discovering/exploiting vulnerabilities in firmware, and wireless hacking using SDR.

Course Outline:

• Module 1: Hunting for UART ports
• Module 2: Hacking Embedded Device with JTAG
• Module 3: Firmware Acquisition
• Module 4:  Basics of Reverse Engineering ARM/MIPS Code
• Module 5:  Embedded Device Vulnerability Assessment
• Module 6:  Embedded Malware Detection and Analysis
• Module 7:  Modifying Firmware for Fun and Profit
• Module 8:  Hacking Wireless Network

Link: IoT / Embedded Device Hacking

Simplify Security Stages

Many people, even some CISO, have no idea there is a different driving factor for different security generation.

With many years in working in Cybersecurity world, I found that there are different generation of Cybersecurity, just like the gen-X and gen-Y. And these Cybersecurity generation is driven by different factors depends on which stage the company at.

I called this Simplify Security Stage. Here is the different driving factor in different generation/stage. 

1. Generation 1 - (driving by Network Security)
2. Generation 2 - (driving by Application Security)
3. Generation 3 - (driving by Identity, Access and Management)

During the security generation 1, every company is focusing on network security. Thus, a successful Cybersecurity program is largely depends on how the network security performs. 

I started my security career in 1999, there it is when the security generation 1 started for most of the company. At this stage, whenever we talk about security architecture, we are talking about network security.

At around 2005, security generation 2 becomes more popular. Everyone in Cybersecurity starts talking about Application Security, penetration testing, and ethical hacking. 

And at around 2011, web application security is focused by almost everyone including IT personnel. To me, I'm still considering it as stage 2. And at this stage, the driving factor for a successful Cybersecurity team is how your application security works. This is also where the time everyone is talking about SDLC and application security framework. Most of the time, people like to refer to application architecture as security architecture.

Starting from 2016 (actually back in 2008/2009) the cloud-based infrastructure becomes a hot topic for enterprise. Many new terms such as SaaS/PaaS/IaaS or even XaaS describes how the new generation has begin to change how things work. 

IMO, the Identity-Access-and-Management or IAM, will be the key driving factor for a successful Cybersecurity organization in stage 3. 

This is simply because of the cloud infrastructure is far more complicated and accessible comparing to the stage 2. Look at the AWS/Azure/GCP configuration, everything start from IAM. To me, IAM will be used to describe the next security architecture. Thus my prediction for stage 3 security, most attack will be focusing on testing how IAM will perform, like how we focusing on network security and application security in the past.

So, at what stage your company today? Start learning to be the key driving factor for next generation of Cybersecurity.