Here my Problem:
If I am connected to a network (so I know the WPA/WPA2-PSK), I´d like to be able to decrypt the traffic I capture from other devices in the network.
(If WEP is used, tcpdump does this automatically).
As far as I know, WPA uses something like a session key for each client in the WiFi - but I know this is possible - so I´m wondering HOW to do this. (If this is not possibile with tcpdump, how to do this "by hand"?)
Thanks for any help!
I've written a small, open source, application that does exactly this.
If you capture the traffic with tcpdump and can save it to file you should be able to use Wireshark to decrypt it on a PC/Mac. You need to catch the association traffic and the four-way handshake and configure Wireshark with the PSK.
TamoSoft has CommView for WiFi product which does what you need. As far as I know, decrypting WPA is a tricky task, and this is what they charge for.
Related
I have multiple clients sending data to a central server. Is there a way I can ensure that the server get the data but in no way it can associate sender with the data.
If the clients are identified using IP address, then spoofing is a way to make sure that they are not traceable. To spoof, you need to identify the packets the client is sending to the server. In Network layer, you shall find the IP bits, which you need to replace(or remove, if it works).
(Use wireshark tool, it might be helpful)
Although, it shall still be considered a malpractice in the society. I sincerely advice you to contact the server administration, to discuss and put in place other security measures instead of spoofing.
Lets assume I have a VoIP service on several servers in different location and I have clients all over world.
When client make request I should be able to reply back to my client which server to use for RTP which will use a lot of data. I believe I can do this simply by checking user IP. Probably I should choice server which have less hops between itself and client, but off cause it do not guarantee best speed or lowest delay.
Is there any API for this or how is possible to achieve this? I will not consider ping or trace-route for this.
Thank you!
You can just send an echo request from clients to all your servers and use the server from where the first answer was received. This can be a simple UDP packet and you need to make this only at first launch and remember the answer.
Tough question. It has to do mainly with security, but also computers. Probably not been done yet.
I was wondering, is it possible to host for example a web application, yet be able to hide *where* the actual server is, and, or who is the originator, making it very very hard ( practically impossible ) for some one to track the origin of the server, and who is behind it?
I was thinking that this might be possible through a third party server, preferably with an owner unrelated to the proxy sites. But the question then also becomes an issue of reliability *of* the third party.
Does the TOR network have support for registering for recieving incoming requests rather than outgoing ones? How secure would that be? Might it be possible that the TOR network has been infiltrated by for example a big goverment ( read USA ) ( dont get angry, please enlighten me as I do not know much of how the TOR network is hosted ).
How can one possibly create such a secure third party server, that preferably does not even know who the final recipient of the request is? Third party companies might be subjected *to* pressure from goverments, either directly from powerful *nations* such as USA, or by the USA applying pressure on the goverments of the country where the server is, applying pressure on the company behind it, and force you to enable a backdoor. ( Just my wild fantasy, think worst case scenario is my motto :) ).
I just came with the idea, that being that this is probably *impossible*, the best way would be to have a bunch of distributed servers, across several nations, make it as hard as possible to go through each and one of them to find the next bouncing server. This would have to be in a linked list, with one public server being registered on a DNS. If compromised, the public server needs to be replaced with another one.
request from user0 -> server1 -> server2 -> server3 -> final processing server -> response to user0 or through the incoming server chain.
When sending a response to someone, could it be done using UDP rather than TCP and hide who the sender was ( also in a web application ) ? So that a middle man listening on user0 computer incoming responses ( and outgoing requests ) do not figure *out who the final* processing server is, if we decide to respond directly to user0 from the final processing server?
The IP of server1 will be public and known to anyone, server1 will send the message to server2 and it is possibly to figure out by listening directly behind server1 traffic node, but perhaps it could hide its own origin if not being listened to directly, so that if big goverments have filters on big traffic nodes or routers, they wouldn't be able to track who it came from, and therefore what the message to server2 is intended for. It would blend in with all other requests.
Anyhow, if you have followed my thoughts this far I think you should know by now what I am thinking about.
Could this be possibly through a P2P network, with a central server behind it, and have the P2P network deliver it to the final server respond in some pattern? The idea is to have one processing server, and then have "minor", "cheaper" servers that acts as proxys?
Why I keep saying central server, is that I am thinking web. But any thoughts on the matter is interesting.
For those that wonders, why... I am looking into creating as secure as possible, and that could withstand goverment pressure ( read BlackBerry, Skype and others ).
This is also a theoretical question.
PS.
I would also be interested in knowing how one have a distributed SECURE database ( for keeping usernames, friendlists and passwords for example ) but this time, it is not neccessery for it to be on the web. A P2P software with a distributed secure database.
Thanks!
Yes, you're reinventing Tor. You should research Tor more fully before going further. In particular, see Hidden Service Protocol. Tor is not perfect, but you should understand it before you try to reinvent it.
If you want to find an ant's nest, follow the ants. If you want to find the original server, follow the ip packets. If you meet a proxy server not willing to provide their path, call the server administrator and have your men in black put a gun on his head. If he does not comply, eliminate the administrator and the server. Carry on following the ants in their new path. Repeat the operation until server is reached or server can't communicate anymore.
So no, you can't protect the origin and keep your server up and running when your men in black can reach any physical entity.
Let's say I want to make an application where stored data is encrypted so only my application is able to read it.
But I want the application to be accessed only if the user is on a particular network.
For instance the application is an Android app that deals with medical records in a hospital.
How to be sure that the device is connected to the network of the hospital ? The idea is that outside this network, the app won't work.
The question is not particularly related to wireless networks, wireless devices or Android, this is general to programming and network identification.
Could a certificate do that ? I'm new to this.
Does a network "identifier" could be faked ? For instance I'm pretty sure that a WiFi SSID is easy to fake.
Cheers.
More details:
Let's assume that the point of the local data is not for an "offline mode", but to avoid network latency. In that case, the data needs to remain accessible only if connected to a particular network, in case the device is stolen.
But if there is no way to be sure of the network's identity... What about a server that would answer to the question "Heya am I on the right network ?" and if no response comes out I know that I'm not on the right one ? (Or that the server just does not respond...) But, again, if the app is hacked, that can be faked too.
Interesting problem.
Generally speaking the purpose of storing data locally is so that it can be accessed while "offline".
However, I think there may be some underlying misconceptions here. Presumably the only reason you'd want to do this is to try and prevent a stolen device from giving up it's secrets. Fact of the matter is, you can't. If the device is no longer under your physical control then it's just a matter of time before it can be hacked.
If we are talking about sensitive data, it shouldn't be stored on the devices. Instead the device should retrieve the data it needs from your server when it needs it and delete it locally when no longer necessary.
The fact that you want the device to only work when connected to your local network implies that you can accomplish this goal.
As a side note, this is why things such as "remote wipe" exist. It's also why every time the device connects to your network it needs to test it's authentication and authorization. Point is if someone reports the device lost or stolen then you need to be able to ban it from your network AND, if the device supports this, remotely disable it.
Bearing in mind that it is entirely possible to pull a device from the network and therefore disable a remote wipe from executing.
With that out of the way, there is absolutely no way you can ensure the device is on a given network. All of that can be faked. It's kind of trivial to setup a router of a given name and change it's MAC to masquerade as whatever, and assign it certain IP addresses. For all intents and purposes it could be made to look exactly like an access point you have... And that's just with normal run of the mill wireless routers you can buy at your local computer store.
You could write your program so that the key to decrypt the data is stored on a server on the hospital network. If your program never stores the key, it makes it harder (although not impossible) for someone to access the device's data outside of the network.
As Chris pointed out a remote wipe would definitely be desirable. You could put in logic so that if the device ever attempts to read the data while not connected to the network, it wipes the data (this might lead to unintended wipes). Blacklisting is good too, so that if the device tries to reconnect to the network, you can essentially brick it. One thing that would be really bad is if you have a network outage, and all your devices accidentally get wiped.
Any network can duplicate another's SSID, so that's not reliable. You could start using a combination of SSID and a MAC address of a known router, but MAC addresses can be duplicated (although not on the same network) so that doesn't work either.
Frankly, unless the wireless network in question is using certificates to identify devices you're going to have no reliable way do it it, and even then this supposes you have a way in your application to get the certificate used the wifi network returns during network authentication.
Perhaps you could use IPSec tunnels. Many routers and firewalls support IPSec. What I'm thinking is something like this:
-----------------------------------
/ IPSec tunnel \
+---------+ \
A | IPSec | B Untrusted \
trusted network -------| capable |------- Networks ----------- Your application
| router | Internet, etc.
+---------+
The gateway router/firewall that provides access for the trusted network has an IPSec tunnel configured between itself and your application. On both the router and your application server, the tunnel looks like another network interface. A route on the router directs traffic for your application to the tunnel interface. A filter can be used on the router to ensure traffic is forwarded to the tunnel only if it arrives on interface A (i.e. the trusted network). Traffic arriving on interface B destined to your application can just be dropped by a filter on the router since it's obviously going the wrong way.
If your application binds its listening socket to just the tunnel interface, you'll know you're only accepting connections received over the tunnel.
You can use whatever combination of encryption and authentication mechanisms you want to to ensure the traffic is secure. Most IPSec implementations support just about anything you could want.
I have a black-box device with a modem attached (which I can send commands to), and would like to be able to connect to send data to a server from it. What connectivity options do I have, is PPP the protocol I need to use or is there a better option?
ppp is certainly the most common solution for getting an IP connection over a modem. There are other solutions, but there's no reason not to use PPP if what you need is an IP connection.
If you don't need an IP connection and you're writing both the client and the server, you could also do a straight serial connection from one modem to another, but that's kind of old-school.
PPP is probably your best option, if you also want an IP gateway and routing. If you only need terminal access to the device, and it runs some form of *nix, you probably have getty+serial communication as an option. You can use any number of modem terminal clients on the other side.