I have started studying Wireless Security and in WEP security, there is something called fake-auth attack. I know it sends an authentication request and then associates with the AP and then we can proceed to an arp replay attack. I need to know how exactly the fake-auth attack works, because if we do not have the WEP key, how can we authenticate and then associate with the AP to replay ARP packets.
The explanation is pretty simple, an access point must authenticate a station before the station can associate with the access point or communicate with the network. The IEEE 802.11 standard defines two types of WEP authentication:
Open System Authentication (OSA): allows any device to join the network, assuming that the device SSID matches the access point SSID. Alternatively, the device can use the “ANY” SSID option to associate with any available access point within range, regardless of its SSID.
Shared Key Authentication: requires that the station and the access point have the same WEP key to authenticate.
A detailed tutorial on how to perform a fake-auth using shared key authentication here.
UPDATE: How can we associate to the AP without the key?
The fake authentication attack on the WEP protocol allows an attacker to join
a WEP protected network, even if the attacker has not got the secret root key.
IEEE 802.11 defines two ways a client can authenticate itself in an WEP protected
environment.
The first method is called Open System authentication: a client just sends a message to an access point, telling that he wants to join the network using Open System authentication. The access point will answer the request with successful, if he allows Open System authentication.
As you can see, the secret root key is never used during this handshake, allowing an attacker to perform this handshake too and to join an WEP protected
network without knowledge of the secret root key.
The second method is called Shared Key authentication. Shared Key authentication uses the secret root key and a challenge-response authentication mechanism, which should make it more secure (at least in theory) than Open System authentication, which provides no kind of security.
First, a client sends a frame to an access point telling him, that he wants to join
the network using Shared Key authentication. The access point answers with a
frame containing a challenge, a random byte string. The client now answers with
a frame containing this challenge which must be WEP encrypted. The access
point decrypts the frame and if the decrypted challenge matches the challenge
he send, then he answers with successful and the client is authenticated.
An attacker who is able to sni an Shared Key authentication handshake can
join the network itself. First note, that besides the APs challenge, all bytes in
the third frame are constant and therefore known by an attacker. The challenge
itself was transmitted in cleartext in frame number 2 and is therefore known by
the attacker too. The attacker can now recover the key stream which was used
by WEP to encrypt frame number 3. The attacker now knows a key stream
and the corresponding IV which is as long as frame number 3.
The attacker can now initiate an Shared Key authentication handshake with
the AP. After having received frame number 2, he can construct a valid frame
number 3 using his recovered key stream. The AP will be able to successfully
decrypt and verify the frame and respond with successful. The attacker is now
authenticated.
Reference here.
Related
I wrote a small Chat application, where users can write each other messages:
On first Login, a user will generate a public/private keypair, derived from the users password.
The public-key will be sent to the server (database).
If a user (A) wants to write user (B) a message, user A encrypts the message with the public key of user B and sends it to the server (and the server will send it then to user B).
But what, if somebody with database-access will change the public-key of user B in the database? Then the attacker can read all messages.
Is it somehow possible to authenticate the public key in the database and make sure, it was not changed and it 100% belongs to user B?
So you're trying to protect against the scenario where an attacker has control over the server and the server cannot be trusted. Since you can't trust any information by the server, you cannot use it directly in any form of verification either. The server can only be relegated to being a dumb transport, and the verification needs to happen directly against the other peer.
Being able to exchange the key out-of-band would help a lot here, meaning you can somehow facilitate a direct peer-to-peer exchange of the key. Since it is difficult to trust the identity of a random remote peer over the general internet, you'd need to employ a strategy like Threema: you can get any remote peer's public key anonymously, but your relationship to this peer is not verified then. Only if you're able to meet in person and exchange/verify keys by physically scanning each others QR codes is the key trustworthy.
To facilitate any sort of key exchange with a remote peer via an untrustworthy server, you'd basically need to implement a Diffie-Hellman key exchange; the server can facilitate the communication, but will have no visibility into what data is being exchanged. This will have to happen with both peers being online at the same time (or it's a very slow offline back-and-forth), so may be somewhat problematic in practice depending on your use case.
I am looking into ways of securing the channel between my client apps and the server.
I have a rich desktop client (win) and mobile client connecting to a webservice, exchanging data.
Using SSL certificates, server and clients may trust each other. On the secured connection i can exchange username and password and therefore authenticate the user.
However i have certain circumstances where a user must connect to the server via any of the two methods without his credentials but only a literal, like say, a license plate number.
I really want to make sure that in this case i ONLY allow client connects from devices i am sure i know, since there is no further checks on the authentication and a license plate number would be a pretty common literal.
How can i ensure that only "devices" which are known to my server, can interact with my server?
If you want to authenticate the device, you'll need to find a way for the device to prove what it is, without disclosing its secret.
A system similar to a number plate would be quite easy to spoof, for anyone in a position to see that number. Depending on how much control you have on this device, you might not be able to hide it, even if the connection to your server is secured with SSL/TLS.
A potential way to do this would be to use a cryptographic hardware token (or smart card). Some of these tokens can be configured to hold a certificate and private key, with the ability to use the private key without being able to export that private key. The cryptographic operations (signing and decryption) happen on the token itself.
You can use these to perform client-certificate authentication to your server. In this case, you would know that the client has that token. This could work on the condition that you know the CAs were issued its certificates only for key pairs in such tokens: there will be a cost in administering the CA to handle this.
This would at least allow you to tie the authentication to a particular token. Whether you can integrate this with your overall device depends on the kind of device you have.
Please check if TLS Pre-Shared Keys (RFC 4279) can be used for your scenario.
I've been reading a few sites on the internet on how SSL works, but I don't understand how exactly it makes things secure. Probably because I don't understand completely how it works.
Let me begin with the core idea of SSL. It is used to encrypt HTTP connections, but for the client and the server to communicate with encrypted data, surely an encryption key needs to be shared. If someone is eavesdropping on your connection, wouldn't they just be able to grab this key and continue listening while decrypting the data? I can image this technique would work if we're talking about a long term connection, but HTTP requests are often completed within half a second.
Let's assume this is somehow taken care of. The other utilisation of SSL is to verify if a server is exactly who it says it is. What prevents a rogue server from faking a certificate signed by a root certificate provider? In none of the descriptions I've read, the browser actually contacted one of these authorities to verify the certificate with them. Let's assume the certificate is encrypted with a private key by the root certificate authority, how is the browser able to verify the data in this certificate without knowing the decryption key? Or is the decryption key different from the encryption key?
One solution to these problems I can imagine is if the certificate and key are only sent once and are stored along with the domain and IP address in your browser.
Thanks for explaining in advance.
First, some basic concepts about public key cryptography:
This relies on a pair of keys. One is the public key (which can be distributed); the other one is the private key, intended to be kept private.
You can encrypt data using the public key, which the private key can decrypt/decipher.
You can sign data using the private key, and this signature can be verified using the public key.
To make sure you're communicating with the right entity, you need to bind an identity to a key-pair. This is where certificates come in. A public key certificate is a signed document containing both the subject's identity (name) and the subject's public key.
For example, the certificate for www.google.com contains its public key and the name www.google.com. It has been signed using the private key of a Certification Authority (in this case, Thawte). In the X.509 terminology (the common standard for certificates used for HTTPS), the CA is the issuer of the certificate, and it puts its name in the certificate too, alongside the subject's name, the subject's public key (and other attributes). The issuers are meant to verify the identity of who they issue a certificate for.
The reason you don't necessarily see your browser fetching information from the CAs is that a number of commercial (or governmental) CA certificates are bundled with your browser or your OS. You trust them by default. This can be considered as a "leap of faith", but any trust mechanism needs this sort of starting point.
You may want to read more about the TLS handshake, but in short:
The client gets the server's public key by looking into its certificate.
The client encrypts a secret using this public key and sends it to the server. The details of this depend on the cipher suite (could be Diffie-Hellman based), but the result of this should be a list of shared encryption keys (using symmetric cryptography, not public key cryptography).
These shared keys are only known to the client and the server, and they're used for encryption/decryption.
For SSL/TLS to be secure, you need at least 3 points:
A suitable cipher suite, and a successful handshake.
Verifying that the client trust the server certificate (typically, via a known CA in the PKI model).
Verifying that the certificate belongs to the server the client intended to contact (hostname verification).
(This is the case for the vast majority of usages of SSL/TLS (in particular HTTPS), but it's also possible to use other mechanisms than X.509 certificates with TLS, for example OpenPGP certificate or Kerberos cipher suites. This is less common as far as I know.)
In order to encrypt a connection you have to agree to some shared secret. This can be done with diffie-hellman. To prevent man in the middle attacks, so you also need a certificate mechanism.
For encrypting or signing (certificates) you can use asynchronous keys. This means you have two different keys (public and private key) to encrypt/decrypt. Usually you encrypt your data with a public key, and someone can decrypt it with his private key. Signing is done with your private key, and someone else can check it with a public key.
So you see, faking a certificate is not that easy, since you don't have the private key from a root certificate provider.
surely an encryption key needs to be shared. If someone is eavesdropping on your connection, wouldn't they just be able to grab this key
No. The key is never transmitted. It is computed at both ends independently via a key-agreement algorithm.
What prevents a rogue server from faking a certificate signed by a root certificate provider?
The certificate is sent along with its digital signature which is made with the private key, and verified by the peer via the certificate's own public key. The server would need the private key of the server it is spoofing.
When using protocols such as Diffie-Hellman key exchange, the two parties to a communication each generate a random number, transform it in some way, and send the transformed version to the other party. The transformation is such that combining the first number with the transformed version of the second will yield the same result as combining the second number with the transformed version of the first. An adversary who only had the transformed numbers, however, would have no way of finding the un-transformed version of either, nor a way of computing what the result would be if the (unavailable) untransformed version of one number were combined with the (available) transformed version of the other.
Diffie-Hellman key exchange by itself would be sufficient to protect against all forms of passive attack or historical attacks (meaning if an attacker hadn't taken steps to intercept a communication before it took place, it cannot later be compromised except by performing some calculations which could not, with anything resembling today's technology, be computed in any remotely feasible time). The problem with it is that it cannot very well protect against the situation where an attacker (e.g. Z) can intercept all communications between the participants (e.g. X and Y) and substitute his own. In that scenario, X would establish a connection with Z--thinking him to by Y--which nobody but he and Z could decode. Z would then--pretending to be X--establish a connection with Y.
If X and Y have any pre-existing means of sharing information with each other in such a way that they can decode it much faster than Z, even if it's not terribly secure, this may suffice to prevent the above-described man-in-the-middle attack. All that needs to happen is for X and Y to ask each other something about the key they're using. If Z can recognize that question and substitute its own answer, it would be able to continue the ruse. On the other hand, if the question were asked in such a way that a legitimate party would be able to respond much more quickly than an imposter, Z might be stumped. As an example, if a voice-phone application displayed for each participant information about the negotiated key, and one party asked the other "read off digits 12 to 18 of your key, doing your best impression of Elmer Fudd" (selecting, on the spot, the digits to read and the voice to use) a legitimate participant would be able to respond immediately, but an attacker would need time to produce a phony recording of the person speaking as indicated).
Why does the Kerberos protocol not feature perfect forward secrecy?
The technical reason is as follows:
The Kerberos protocol in its basic
form does not provide perfect
forward secrecy for communications.
If traffic has been recorded by an
eavesdropper, then messages encrypted
using the KRB_PRIV message, or
messages encrypted using
application-specific encryption under
keys exchanged using Kerberos can be
decrypted if the user's,
application server's, or KDC's key is
subsequently discovered. This is
because the session key used to
encrypt such messages, when
transmitted over the network, is
encrypted in the key of the
application server. It is also
encrypted under the session key from
the user's TGT when it is returned to
the user in the KRB_TGS_REP
message. The session key from the TGT
is sent to the user in the
KRB_AS_REP message encrypted in the
user's secret key and embedded in
the TGT, which was encrypted in the
key of the KDC. Applications
requiring perfect forward secrecy must
exchange keys through mechanisms
that provide such assurance, but may
use Kerberos for authentication of
the encrypted channel established
through such other means.
Basically perfect forward secrecy adds additional overhead to the protocol that is not necessary for many of its applications. If you need PFS, then you can add it. What does matter to most Kerberos users is speed. If you have tens of thousends of employes all over the world all authenticated at the same time, then the overhead required for PFS is going to be too expensive and there for not practical.
Our clients call our web service over SSL and authenticate themselves with a username and password. Our server then generates a symmetric key and sends it back to the client.
Then, the client establishes a TCP connection to our server, and sends a login message. At this point, I want to authenticate the client.
My idea is to have the client encrypt a well-known/static piece of text with the symmetric key and use this as proof that it is in possession of the key.
Since the symmetric key is generated randomly, is it ok that I use a static piece of text here?
Any input appreciated.
SSL is built to authenticate both client and server, and asymmetric cryptography the most secure primitive you can use in this scenario. Symmetric ciphers can be used for authentication by using a Cipher Block Chaining Message Authentication Code other wise known as CBC-MAC mode. The use of CBC-MAC has similar protection as an HMAC, but utilizing a symmetric cipher instead of a message digest function. CBC-MAC mode is used by WPA to protect wireless networks.
Your idea is subject to a replay attack - if someone observes a user logging in, they can store the static-text-encrypted-with-symmetric-key and use it later to authenticate themselves.
The accepted way of doing this is a challenge/response. The client connects, the server generates a random challenge and sends it to the client, and the client responds with the encrypted version of the challenge (although you should actually use a HMAC here, rather than a block cipher, because otherwise your client is effectively a one-block decryption oracle!). It would also be safer to use two different random keys (provided at the same time over the web service), one for encryption and one for authentication.
Note though that this scheme, as written, is still susceptible to a man-in-the-middle attack. You are definitely better off using SSL, as The Rook suggests. This will require your client to generate a public key and send it to the web service. The web service responds with a signed certificate containing the client's public key along with the client's unique identifier (username, or whatever) in the DN field. The server on the separate connection verifies the client certificate used (ensuring it's signed by your web service), and verifies that the client identifier in the certificate matches the client that is asking to connect.