I need to fully understand the IPSec Phase 1 negotiation.
now, I break this to 3 steps:
Algorithm negotiations
Key Exchange Data
Identification
I'm using Wireshark to investigate the process and so far I fully understand the first part (Algorithm Negotiations).
My current problem lies in the 2nd part: Key Exchange Data.
The algorithms in use are AES-CBC-256bit, Pre-shared key, MD5 & 1024 bit Group.
The "ISAKMP Payload"->"KeyExchange Payload"->"KeyExchangeData" is beyond me...
I have no clue what it is.. an MD5'ed pre-shared key? Is it encrypted?
See draft-kivinen-ipsecme-ikev2-minimal-01. It does a pretty good job explaining on what is needed for IKEv2 protocol
ISAKMP / IKEv1 / IPSec phase 1 is a bit more complicated, but most things in IKEv2 are somewhat analogous to the older version - and certainly help in learning the more complex stuff.
Key exchange data in the KE payload is just the Diffie-Hellman "shared secret". If you are literate with python code, see this project. There is also a module that can do the math and has some of the most used DH group's primes.
This page should help to understand IPSec.
Related
This is the article published by Microsoft for encrypting/decrypting data using RSA:
https://learn.microsoft.com/en-us/dotnet/standard/security/walkthrough-creating-a-cryptographic-application
As a relatively new person into the cryptography world and having read a comment on stackoverflow saying that cryptography should use a hybrid model, I researched that and it seems that hybrid models use AES and RSA for encryption and I was wondering if the example provided by Microsoft fits into the hybrid model since it uses both and if is constructed well enough and not just for novice devs just venturing into the world of cryptography.
I already have a working example where an app would encode and another would decode by loading the private key file, similar to the example.
I found an article here:
https://www.codeproject.com/Tips/834977/Using-RSA-and-AES-for-File-Encryption
He creates signatures and manifests and I'm wondering if this is what I'm looking for is Microsoft's example generally just enough, or weak?
PS: I removed the key container code and persistence as I don't want to persist or store my keys on the local machine, instead they are exported as standalone files to be stored in a DB maybe, so I'm not looking for opinions on that part at the moment.
and not just for novice devs just venturing into the world of cryptography
Well, at least it tries to define some kind of protocol, although very sparse. It also uses CBC mode (implicitly, never a good idea) and RSA with PKCS#1 v1.5 padding for encryption. Most people would opt for OAEP if RSA is used and use an authenticated cipher such as GCM.
I already have a working example where an app would encode and another would decode by loading the private key file, similar to the example.
Bad idea, the example is for file encryption, not for transport mode security, for which you need a secure transport protocol. Both the RSA implementation and CBC implementation are malleable, and are both susceptible to padding oracle attacks as well.
I don't want to persist or store my keys on the local machine
You need to establish trust, something that is missing from the example. And to establish trust you do need to persist your keys, especially if they have been randomly generated.
In the end, asking if something is secure depends on context: you need to know what your goals are and then check if the protocol provides enough protection to achieve these goals.
This is also my problem with these generic examples or wrapper classes; they make no sense to me, as the generic security that they seem to provide may not fit your use case; I'd rather design a protocol specific to the use case.
I need to implement an authentication procedure between a reader an NFC tag but being my knowledge limited in this area I will appreciated some aid in order to understand few concepts.
Pardon in advance for rewrite the Bible but I could not summarize it more.
There are many tags families ( ICODE, MIFARE, NTAG...) but after doing a research I think NTAG 424 DNA matches my requirements(I need mainly authentication features).
It comes with AES encryption, CMAC protocol and 3-pass-authentication system and here is when I started to need assistance.
AES -> As I am concerned this is a block cipher to encrypt plain texts via permutations and mapping. Is a symmetric standard and it does not use the master key, instead session keys are used being them derivations from the master key. (Q01: What I do not know is where this keys are stored in the tag. Keys must be stored on specialized HW but no tag "specs" remark this, apart from MIFARE SAM labels.)
CMAC -> It is an alteration of CBC-MAC to make authentication secure for dynamically sized messages. If data is not confidential then MAC can be used on plain-texts to verify them, but to gain confidentiality and authentication features "Encrypt-than-mac" must be pursuit. Here also session keys are used, but not the same keys used in the encryption step.(Q02: The overall view of CMAC may be a protocol to implement verification along with confidentiality, this is my opinion and could be wrong.)
3-pass-protocol -> ISO/IEC 9798-2 norm where tag and reader are mutually verified. It may also use MAC along with session keys to achieve this task.(Q03: I think this is the upper layer of all the system to verify tags and readers. The "3 pass protocol" relays in MAC to be functional and, if confidentiality features are also needed, then CMAC might be used instead of single MAC. CMAC needs AES to be functional, applying session keys on each step. Please correct me if I am posting savages mistakes)
/*********/
P.S: I am aware that this is a coding related forum but surely I can find here someone with more knowledge than me about cryptography to answer this questions.
P.S.S: I totally do not know where master and session keys are kept in the Tag side. Have they need to be include by a separate HW along with the main NFC circuit ?
(Target)
This is to implement a mutual verification process between tag and reader, using the NTAG 424 DNA TagTamper label. (The target is to avoid 3º parties copies, being authentication the predominant part instead of message confidentiality)
Lack of knowledge of cryptography and trying to understand how AES, CMAC and the mutual authentication are used on this NTAG.
(Extra Info)
NTAG 424 DNA TT: https://www.nxp.com/products/identification-security/rfid/nfc-hf/ntag/ntag-for-tags-labels/ntag-424-dna-424-dna-tagtamper-advanced-security-and-privacy-for-trusted-iot-applications:NTAG424DNA
ISO 9798-2: http://bcc.portal.gov.bd/sites/default/files/files/bcc.portal.gov.bd/page/adeaf3e5_cc55_4222_8767_f26bcaec3f70/ISO_IEC_9798-2.pdf
3-pass-authentication:https://prezi.com/p/rk6rhd03jjo5/3-pass-mutual-authentication/
Keys storage HW:https://www.microchip.com/design-centers/security-ics/cryptoauthentication
The NTAG424 chips are not particularly easy to use, but they offer some nice features which can be used for different security applications. However one important thing to note, is that although it heavily relies on encryption, from an implementation side, that is not the main challenge, because all of the aes encryption, cmac computation and so on is already available as some sort of package or library in most programming languages. Some examples are even given by nxp in their application note. For example in python you will be able to use the AES package from Crypto.Cipher import AES as stated in one of the examples of the application note.
My advice is to simply retrace their personalization example beginning at the initial authentication, and then work your way up to whatever you are trying to achieve. It is also possible to use these examples in order to test the encryption and the building of apdu commands. Most of the work is not hard, but sometimes the NXP documents can be a bit confusing.
One small note, if you are working with python, there is some code available on github which you might be able to reuse.
For iOS, I'm working on a library for DNA communication, NfcDnaKit:
https://github.com/johnnyb/nfc-dna-kit
Recently, I was pointed to a post from 2011 by a friend, which described Google's move towards forward secrecy. From what I understand, the essence of forward secrecy seems to lie in the fact that the private keys are not kept in persistant storage.
I have various doubts about how something like this could be implemented.
What if the server goes down without warning - do the key pairs have to be regenerated? Does the public key have to be signed again to create another certificate?
Could someone point me to posts/pdfs where the implementation of something like this is described. Suggested reading resources?
Are you aware of anyone else that has implemented forward secrecy? Have you tried something similar at your workplace?
Thanks!
In Forward Secrecy, there are still long-term keys. The only implication is, that the compromisation of a long-term key will not allow an attacker to compromise temporary session keys, when the long-term key has changed. This means that a long-term key must not be derived from another (older) key.
Here is a good survey on this topic.
According to Wikipedia:
PFS is an optional feature in IPsec (RFC 2412).
SSH.
Off-the-Record Messaging, a cryptography protocol and library for many instant messaging clients, provides perfect forward secrecy as well as deniable encryption.
In theory, Transport Layer Security can choose appropriate ciphers since SSLv3, but in everyday practice many implementations refuse to offer PFS or only provide it with very low encryption grade.
In TLS and many other protocols forward secrecy is provided through the Diffie-Hellman (DH) algorithm. Vanilla DH is rather simple and provides perfect forward secrecy if the exponents are randomly generated each time, but provides no authentication. Therefore in TLS it is using in combination with a signature algorithm, usually RSA.
TLS provides many ciphersuites that support PFS and many that do not. Most TLS clients support PFS but many servers do not, because it is thought that PFS takes too much CPU.
Does anybody know some simple authentication and data transfer protocol based on symmetric keys only? Due to memory constraints (kilobytes RAM and ROM) we cant afford asymmetric cryptography and due to closed environment asymmetric cryptography does not increase security of any way.
I am looking for simple symmetric cryptography protocol that can be kept in head and written on one paper sheet. I was looking in EAP-PSK https://www.rfc-editor.org/rfc/rfc4764#page-4 but still think that 2^6 pages is way to much for something simple and secure.
Does anybody know some useful url, paper or idea?
For secrecy, use AES-CBC. For message authentication, use HMAC-SHA256. Use a different key for each.
In both cases, use an existing, validated, timing-attack-free implementation of the cryptographic primitives.
I think you're looking for the Diffie-Hellman key exchange: only requires bignum integer arithmetic (powers, multiplication, and modulus only, at that): http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
This is a question about an authentication scheme.
Say I have a shared secret string S, and two computers, C1 and C2
Computer one (C1) sends a random string (R) to computer two (C2)
C2 hashes (say SHA256) the concatenation of S and R (SR)
C2 sends the hash of SR to C1, along with some instructions
C1 compares the received hash of SR with it's own hash of SR and executes the instructions if they match
Wash, rinse, repeat with different values of R
Now, what I want to know is if someone intercepts a whole bunch of R values, and a whole bunch of SR hashes, can they use that as a "crib" to work out what S is, thus allowing them to forge instructions?
I'm already aware of the potential for a MITM attack here (attacker intercepts response, changes the instructions and forwards it on).
I honestly don't know what I'm dealing with here, I only have a bit of historical knowledge about encryption but that included the use of cribs to break them. I'm not a theorist, so anything you can definitively tell me about specific strong hashes would be great.
Alternate authentication schemes are also welcome, assuming the constraints of an existing shared secret string like in this example. Would I be better off just using S as a key for AES? If I do that, can I still use this in the encrypted message to prevent replay attacks?
Any and all advice welcome, I sort of deviated from my question at the end, so feel free to deviate in your answers!
What you're talking about is called a message authentication code - a MAC. If the secret is sufficiently large (such that it cannot be brute forced in reasonable time) and the MAC is properly implemented, then no, knowing the plaintext doesn't help the attacker.
The key, however, is that it has to be properly implemented. The problem is that crypto is hard. Really hard. Unless you're an expert or have an expert to review your work in context, it's extremely easy to make a mistake. Even worse, it's very easy for people to write crypto that they don't know how to break, but which can be broken quite easily by someone in the know.
The advice you got in the comments is the correct advice: use a proven scheme like SSL or TLS instead of creating your own.
Answering your question:
No, the only way to break a hash is brute force, as small diferences in the origin mean big differences in the output of the hashing algorithm (given that the algorithm has been proben to be unbroken). You must to know S to perform a MITM here.
But, Byron Withlock is correct:
Using a homemade encryption scheme when there are sooo many better schemes available is crazy. Leave encryption to the experts. – Byron Whitlock 4 mins ago
I'm with Byron. Just use something off-the-shelf and tested by people with a clue. How about SSL? – Steven Sudit 57 secs ago
Many cryptographic hash functions are vulnerable to a lengt extension attack. That means if an attacker knows hash(S) but not S, then he may still be able to compute hash(S || M) for some messages M. For example, the attacker might try to get hash(S), by sending the challenge string "" to one of the parties. Your scheme does not have a detailed description. So it is not clear if such a length extension attack is possible. To avoid these kind of attacks you might consider to use for example HMAC instead of the more simple hashing scheme that you propose.
This scheme is weak because the instructions themselves aren't authenticated. You want to send the MAC of R + instructions - and ensure that R is fixed length so that an attacker can't shuffle about between R and instructions.
I take it the purpose of the random value is to ensure the "freshness" of the instructions sent?
You could also look into using gpg, if SSL doesn't meet your needs. That's likely to be a lot better than homegrown crypto.