Security References: Difference between revisions
Jump to navigation
Jump to search
(New page: == Development == * [http://www.sans.org/top25errors/ CWE/SANS TOP 25 Most Dangerous Programming Errors]) |
|||
(34 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== Conferences == |
|||
* [https://jaif.io/2024/index.html JAIF - Journée thématique sur les attaques par injection de fautes] |
|||
:* Free attendance, slides available online. |
|||
== Standards == |
|||
=== Key derivation === |
|||
* [https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf NIST SP800-108 Recommendation for Key Derivation Using Pseudorandom Functions]. |
|||
== Development == |
== Development == |
||
* [http://www.sans.org/top25errors/ CWE/SANS TOP 25 Most Dangerous Programming Errors] |
* [http://www.sans.org/top25errors/ CWE/SANS TOP 25 Most Dangerous Programming Errors] |
||
* [http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf Reflections on Trusting Trust] How does writing the C compiler in C bear on security issues? Well, it does (Ken Thompson, Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763) |
|||
** The idea is to hide a trojan code in the C compiler so that to inject a trojan code in eg. the <tt>login</tt> command code, and another trojan code so that to automatically re-inject itself when the C code is compiled with the infected compiler. |
|||
* [http://cwe.mitre.org/index.html Common Weakness Enumeration] |
|||
* [http://cwe.mitre.org/data/lists/2000.html CWE-2000: Comprehensive CWE Dictionary] |
|||
** [http://cwe.mitre.org/data/definitions/287.html Improper Authentication] |
|||
== PKI == |
|||
On trust model flaw in browser CAs: |
|||
* ''"it will CLEARLY not solve the browser security problem.", "the certifications made by even the best of those CAs are effectively MEANINGLESS" "the users are well trained to ignore EVERY browser warning they EVER get" "the ENTIRE question of OCSP is somewhat irrelevant." "spritzing the SKUNK with eau de cologne." "hanging garlands from the corpses ears."''' (Cfr mail '''A mighty fortress is our PKI, Part II''' (ventzi nikov, 2010 Jul 29 09:06) |
|||
== Authentication == |
|||
* [http://www.cacr.math.uwaterloo.ca/hac/ Handbook of Applied Cryptography], chap. 9 and 10.<br/>Definition, objectives, properties... |
|||
== Definitions == |
|||
;Secure Boot |
|||
:''Secure Boot'' <ref name="TCHASK">Löhr, H., Sadeghi, A., Stüble, C., Weber, M., Winandy, M.: {{bibtit|Modeling Trusted Computing Support in a Protection Profile for High Assurance Security Kernels}}. In TRUST(2009) 45-62</ref> is a security property of a bootstrap architecture ensuring that only configurations of a certain property can be loaded. If a modification is detected, the bootstrap process is interrupted. |
|||
;Authenticated Boot |
|||
:''Authenticated Boot'' <ref name="TCHASK"/> is a security property of a bootstrap architecture ensuring that remote parties can verify properties of the booted configuration. |
|||
;Trusted storage |
|||
:''Trusted storage'' <ref name="TCHASK"/> is storage where confidentiality, integrity, and freshness (i.e., protection against replay attacks) of stored data is provided, and where the integrity of the TOE accessing the data is ensured (in order to prevent other software, such as alternative or modified operating systems, from accessing the data). |
|||
;Trusted Channel |
|||
:A ''trusted channel'' <ref name="TCHASK"/> is a channel between two entities that provides integrity, confidentiality, and authenticity of the transmitted data, and ensures integrity and authenticity of the end points. |
|||
;Nonce |
|||
:A ''nonce'' <ref name="HAC">Menezes, A., van Oorschot, P., Vanstone, S.: {{bibtit|Handbook of Applied Cryptography}}, 1997</ref> is a value used no more than once for the same purpose. It typically serves to prevent (undetectable) replay |
|||
;Authentication |
|||
:Assurance that the peer entity is in fact the entity it claims to be. |
|||
== Software == |
|||
* [http://pdos.csail.mit.edu/papers/stack:sosp13.pdf Towards Optimization-Safe Systems: Analyzing the Impact of Undefined Behavior] <ref name="STACK">Xi Wang, Nickolai Zeldovich, M. Frans Kaashoek, and Armando Solar-Lezama: {{bibtit|Towards Optimization-Safe Systems: Analyzing the Impact of Undefined Behavior}}. In SOSP(2013)</ref> |
|||
=== Testing === |
|||
* [https://github.com/minimaxir/big-list-of-naughty-strings Big list of naughty strings] — A list of user input strings that may trigger unexpected behaviour in SW. |
|||
=== Fuzzing === |
|||
* https://github.com/google/syzkaller — syzkaller - kernel fuzzer |
|||
=== ROP === |
|||
* [https://marc.info/?l=openbsd-tech&m=169558749114476&w=2 Viable ROP-free roadmap for i386/armv8/riscv64/alpha/sparc64] |
|||
:Discussion about ROP protection, stack protection, <code>RETGUARD</code> instruction, <code>-fstack-protector-strong</code> flag in clang/gcc. |
|||
== Reverse engineering == |
|||
* [https://cutter.re/ Cutter] - powered by Radare2. |
|||
* Ghidra. |
|||
* IDA Pro. |
|||
* [https://eprint.iacr.org/2024/860.pdf HAWKEYE] — Recovering Symmetric Cryptography From Hardware Circuits (CRYPTO 2024) |
|||
== RSA == |
|||
* Dan Boneh, {{bibtit|Twenty Years of Attacks on the RSA Cryptosystem}}, February 1999, Notices of the AMS, <tt>http://www.ams.org/notices/199902/boneh.pdf</tt> |
|||
* Leo Reyzin, {{bibtit|Notes for lecture 8 — Chinese Remainder Theorem and Blum-Blum-Shub PRG}}, Fall 2004, BU CAS CS 538, <tt>http://www.cs.bu.edu/~reyzin/teaching/f04cs538/notes8.pdf</tt> |
|||
* Jingjing Wang, {{bibtit|Attacks against RSA Cryptosystems in Thirty Years}}, June 2011, <tt>http://cis.sjtu.edu.cn/download/d/df/RSA_Attacks.pdf</tt> |
|||
== Privacy and anonymity == |
|||
* Philippe Golle, {{bibtit|Universal Re-encryption for Mixnets}}. [https://crypto.stanford.edu/~pgolle/papers/univrenc.pdf] |
|||
:Propose a variant of ElGamal encryption, where plaintext can be re-encrypted, hence preventing tracking. The same system can be used to randomize a public key such that encrypted message can still be decrypted by the same private key [https://blog.cryptographyengineering.com/2019/06/05/how-does-apple-privately-find-your-offline-devices/]. |
|||
* Matthew Green, {{bibtit|How does Apple (privately) find your offline devices?}} [https://blog.cryptographyengineering.com/2019/06/05/how-does-apple-privately-find-your-offline-devices/] |
|||
:Description of a system to discover location of a remote offline device via a network of connected devices... in a privacy-friendly way. |
|||
* Hal Abelson, Ross Anderson, Steven M. Bellovin, Josh Benaloh, Matt Blaze, Jon Callas, Whitfield Diffie, Susan Landau, Peter G. Neumann, Ronald L. Rivest, Jeffrey I. Schiller, Bruce Schneier, Vanessa Teague, Carmela Troncoso, [https://arxiv.org/abs/2110.07450 Bugs in our Pockets: The Risks of Client-Side Scanning] |
|||
== Models == |
|||
=== Dolev-Yao attacker model === |
|||
;Eve can: |
|||
* See all messages |
|||
* Delete, alter, inject and redirect messages |
|||
* Initiate new communications |
|||
* Reuse messages from past sessions |
|||
;Eve cannot: |
|||
* Solve “hard” problems (such as?) |
|||
* Guess pseudo-random values (eg. nonces) |
|||
* Get another identity (identity theft) |
|||
* Time computations |
|||
References: |
|||
* Danny Dolev and Andrew C. Yao, {{bibtit|On the Security of Public Key Protocols}}, 1983, IEEE. |
|||
* Pieter Hartel, {{bibtit|Introduction to Information Security}}, [http://wwwhome.ewi.utwente.nl/~pieter/IIS/1-Introduction.ppt] |
|||
=== Other === |
|||
* Colin Boyd, {{bibtit|Towards Extensional Goals in Authentication Protocols}}, 1997. [http://dimacs.rutgers.edu/Workshops/Security/program2/boyd/] |
|||
:Extensional goals are properties independent of the protocol and define what the protocol is designed to achieve. |
|||
== Fault-tolerance == |
|||
* [https://en.wikipedia.org/wiki/Byzantine_fault Wikipedia - Byzantine fault] |
|||
:Byzantine fault is a condition of a computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed. This article covers '''several solutions'''. |
|||
* [https://scholar.harvard.edu/files/mickens/files/thesaddestmoment.pdf The saddest moment] |
|||
:a fun article about the issues of publications over byzantine fault tolerance. |
|||
== References == |
|||
<references/> |
Latest revision as of 09:27, 17 September 2024
Conferences
- Free attendance, slides available online.
Standards
Key derivation
Development
- CWE/SANS TOP 25 Most Dangerous Programming Errors
- Reflections on Trusting Trust How does writing the C compiler in C bear on security issues? Well, it does (Ken Thompson, Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763)
- The idea is to hide a trojan code in the C compiler so that to inject a trojan code in eg. the login command code, and another trojan code so that to automatically re-inject itself when the C code is compiled with the infected compiler.
- Common Weakness Enumeration
- CWE-2000: Comprehensive CWE Dictionary
PKI
On trust model flaw in browser CAs:
- "it will CLEARLY not solve the browser security problem.", "the certifications made by even the best of those CAs are effectively MEANINGLESS" "the users are well trained to ignore EVERY browser warning they EVER get" "the ENTIRE question of OCSP is somewhat irrelevant." "spritzing the SKUNK with eau de cologne." "hanging garlands from the corpses ears."' (Cfr mail A mighty fortress is our PKI, Part II (ventzi nikov, 2010 Jul 29 09:06)
Authentication
- Handbook of Applied Cryptography, chap. 9 and 10.
Definition, objectives, properties...
Definitions
- Secure Boot
- Secure Boot [1] is a security property of a bootstrap architecture ensuring that only configurations of a certain property can be loaded. If a modification is detected, the bootstrap process is interrupted.
- Authenticated Boot
- Authenticated Boot [1] is a security property of a bootstrap architecture ensuring that remote parties can verify properties of the booted configuration.
- Trusted storage
- Trusted storage [1] is storage where confidentiality, integrity, and freshness (i.e., protection against replay attacks) of stored data is provided, and where the integrity of the TOE accessing the data is ensured (in order to prevent other software, such as alternative or modified operating systems, from accessing the data).
- Trusted Channel
- A trusted channel [1] is a channel between two entities that provides integrity, confidentiality, and authenticity of the transmitted data, and ensures integrity and authenticity of the end points.
- Nonce
- A nonce [2] is a value used no more than once for the same purpose. It typically serves to prevent (undetectable) replay
- Authentication
- Assurance that the peer entity is in fact the entity it claims to be.
Software
Testing
- Big list of naughty strings — A list of user input strings that may trigger unexpected behaviour in SW.
Fuzzing
- https://github.com/google/syzkaller — syzkaller - kernel fuzzer
ROP
- Discussion about ROP protection, stack protection,
RETGUARD
instruction,-fstack-protector-strong
flag in clang/gcc.
Reverse engineering
- Cutter - powered by Radare2.
- Ghidra.
- IDA Pro.
- HAWKEYE — Recovering Symmetric Cryptography From Hardware Circuits (CRYPTO 2024)
RSA
- Dan Boneh, Twenty Years of Attacks on the RSA Cryptosystem, February 1999, Notices of the AMS, http://www.ams.org/notices/199902/boneh.pdf
- Leo Reyzin, Notes for lecture 8 — Chinese Remainder Theorem and Blum-Blum-Shub PRG, Fall 2004, BU CAS CS 538, http://www.cs.bu.edu/~reyzin/teaching/f04cs538/notes8.pdf
- Jingjing Wang, Attacks against RSA Cryptosystems in Thirty Years, June 2011, http://cis.sjtu.edu.cn/download/d/df/RSA_Attacks.pdf
Privacy and anonymity
- Philippe Golle, Universal Re-encryption for Mixnets. [1]
- Propose a variant of ElGamal encryption, where plaintext can be re-encrypted, hence preventing tracking. The same system can be used to randomize a public key such that encrypted message can still be decrypted by the same private key [2].
- Matthew Green, How does Apple (privately) find your offline devices? [3]
- Description of a system to discover location of a remote offline device via a network of connected devices... in a privacy-friendly way.
- Hal Abelson, Ross Anderson, Steven M. Bellovin, Josh Benaloh, Matt Blaze, Jon Callas, Whitfield Diffie, Susan Landau, Peter G. Neumann, Ronald L. Rivest, Jeffrey I. Schiller, Bruce Schneier, Vanessa Teague, Carmela Troncoso, Bugs in our Pockets: The Risks of Client-Side Scanning
Models
Dolev-Yao attacker model
- Eve can
- See all messages
- Delete, alter, inject and redirect messages
- Initiate new communications
- Reuse messages from past sessions
- Eve cannot
- Solve “hard” problems (such as?)
- Guess pseudo-random values (eg. nonces)
- Get another identity (identity theft)
- Time computations
References:
- Danny Dolev and Andrew C. Yao, On the Security of Public Key Protocols, 1983, IEEE.
- Pieter Hartel, Introduction to Information Security, [4]
Other
- Colin Boyd, Towards Extensional Goals in Authentication Protocols, 1997. [5]
- Extensional goals are properties independent of the protocol and define what the protocol is designed to achieve.
Fault-tolerance
- Byzantine fault is a condition of a computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed. This article covers several solutions.
- a fun article about the issues of publications over byzantine fault tolerance.
References
- ↑ 1.0 1.1 1.2 1.3 Löhr, H., Sadeghi, A., Stüble, C., Weber, M., Winandy, M.: Modeling Trusted Computing Support in a Protection Profile for High Assurance Security Kernels. In TRUST(2009) 45-62
- ↑ Menezes, A., van Oorschot, P., Vanstone, S.: Handbook of Applied Cryptography, 1997
- ↑ Xi Wang, Nickolai Zeldovich, M. Frans Kaashoek, and Armando Solar-Lezama: Towards Optimization-Safe Systems: Analyzing the Impact of Undefined Behavior. In SOSP(2013)