Software Security Study Group Report 

Week 4

 

Cryptography

In cryptography, we reviewed Integrity rather than the secrecy of communication. We stated that encryption doesn’t have to provide integrity. For integrity we need authentication. To provide authentication we introduced the term “Message Authentication Code” (MAC). In order to construct a secure MAC for short, fixed-length messages, we need a keyed function Mac such that it is infeasible to predict any output based on previous inputs. Then we reviewed the basic “Cipher Block Chain – MAC” (CBC -MAC).

On hash functions, we talked about collision which is basically two different inputs giving the same output H(x) = H(x’). Even though performing a “generic” collision attack seems infeasible, thanks to so-called “Birthday Paradox” it is theoretically possible to find a collision. (http://www.wiki-zero.com/index.php?q=aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvQmlydGhkYXlfcHJvYmxlbQ)

We proved that if we have a collision-resistant Hash and a secure MAC, our HMAC is secure for arbitrary length messages. Then we joined our knowledge about secrecy from previous weeks with integrity. We pointed that if the MAC is deterministic, whether the same message is encrypted twice. That problem is solved my running Mac function on the cipher. This method, called authenticated encryption, is both CPA and CCA secure.

Lastly, on secure communication sessions we defined three attack types named replay attack, re-ordering attack, and reflection attack these attacks can be eliminated by sending identities and counters with the message to create a secure communication session.

 

Software Security

In software security, we learned about how to build a secure software. We reviewed some example threat models and risk analysis methods. We learned that we cannot create a secure software by building the software without thinking about security at first and afterward adding a security layer to our software. Instead, we have to define how an attacker can attack our program, then we should make a security design for our software and keep that design in mind in all of our development processes.

In addition to these, we analysed some common design flaws that will expose some security weaknesses.

Finally, we analysed a secure program "Very Secure FTP Daemon (VSFTPD)" and learned about how they achieved this level of security on a relatively complex program.

See you next week!