c33v33
join:2003-10-14
Chicago, IL | Need opinion on my wireless security. router: Linksys WRT54GS
clients: 2 Linksys WMP11, 1 wired
I can not run any WPA (TKIP or AES) due to hardware limitations. So...
I am using tinyPEAP from www.tinypeap.com on my WRT54GS, which is a firmware that supports PEAP authentication on my wireless network without a dedicated RADIUS server. It is used along with 64-bit WEP.
Is this network secure? I'm paranoid about wireless thieves!!
Can someone rate the "secureness" of each type of wireless security i.e. AES>WEP>MAC filter?
Also, does anyone have that link from Tom's Networking that shows the overhead for each type of wireless encryption?
thanks! |
|
 DaMaGeINCThe Lan ManPremium
join:2002-06-08
Greenville, SC
kudos:2 | As long as thier is some kind of security, no one will bother with you. Wardrivers like myself ALWAYS look for OPEN ap's. |
|
| reply to c33v33
I've just gone to the TinyPEAP web site. It seems that everyone gets to download the same public key, which means that the TinyPEAP RADIUS server has one generic private key. I thought the whole idea behind PEAP was that every entity gets its own private key and distributes the corresponding public key to clients belonging to the same entity. I wouldn't call the TinyPEAP implementation real PEAP. This is no more secure than Cisco LEAP and is vulnerable to the same kind of dictionary attack, in my opinion. Why even mess with PKI when the keys are generic. Why not just implement LEAP, which uses MD4 on usernames and double MD4 on passwords? Can anyone explain? Are they just trying to leverage the PEAP support that various vendors are implementing in their wireless cards? I know for sure that DELL has support for both LEAP and PEAP with WPA TKIP in their wireless cards. Not sure about other vendors, though. I guess since WPA TKIP is more "standard" than Cisco TKIP (a.k.a CKIP), TinyPEAP chose "standard" PEAP over "non-standard" LEAP. Unless they let you install real private keys in their RADIUS server, this is not "completely" secure. So, choose your passwords accordingly lest they should be guessed through a dictionary attack. |
|
| Just re-read the original post. Cee_vee's hardware doesn't even support WPA. Therefore, TinyPEAP will be redistributing static WEP keys, instead of generating a new WEP key for every client. This is much less secure than WPA, WPA-PSK, or Cisco TKIP. In fact, Cisco calls this EAP-MD5 if I'm not mistaken. The only benefit of this authentication over just assigning a static WEP key to the client is that if the WEP key were compromised, the new WEP key wouldn't have to be re-keyed on every client -- it would only need to be changed on the AP. For a home network, the re-keying of a new WEP key is not a big issue. It doesn't look like the AP is going to rotate static WEP keys, so I don't see any benefit in installing this solution at all unless your hardware supports WPA TKIP. The only benefit of the TinyPEAP RADIUS server would be if WPA TKIP could be implemented on clients, which would enable the RADIUS server to generate a new WEP key for every client. This would indeed increase the wireless security since WPA IV+WEP keys don't have to be rotated due to the fact that even with every frame getting a new IV+WEP key, the same combination will not occur for hundreds of years. |
|
c33v33
join:2003-10-14
Chicago, IL
1 edit | This is taken from the tinyPEAP development team from linksysinfo.org
"When using tinyPEAP as your radius server, it is ok to select 64bit encryption. The key is given to you automaticly (you will never know it), and is changed every 5 minutes or so behind your back. This makes it mathmaticly impossible to crack because you cannot feasibly collect enough packets with one key to crack it. Not only that, but if you did somehow figure out the key then it would change in under 5 minutes anyhow. We generally do not see the need to use 128bit encryption since this only adds overhead and doesnt really make things more secure. Using WPA, or more specificly TKIP, is recomended if your hardware supports it. In order to set it up to use WPA, simply choose WPA instead of RADIUS, and fill in the same information. Note however, you do not want WPA Pre shared key. Once again though, this adds more overhead, but WPA has a message integrity check that prevents bit flipping attacks, so it is recommended over 64bit WEP. However, not all hardware supports WPA, which is why the instructions use 64 bit WEP.
On another note, the binary does use Satori, so you need not fear that you are downgrading your firmware. Also, we can put this server on any firmware really, so if you have some suggestions that would be great.
-tinyPEAP deveopment team-
p.s. spread the word on tinyPEAP!"
and also read FDM80's responses on another post I created...
»Advice on WPA Security
So, is my wireless security secure at all? |
|
|
|
| reply to sirozha
quote:
I've just gone to the TinyPEAP web site. It seems that everyone gets to download the same public key, which means that the TinyPEAP RADIUS server has one generic private key.
This means that anyone can authenticate any TinyPEAP server. It would be nicer if each server could be provided with its own private key so I could authenticate my server instead of any server but this is not a major drawback in most situations.
quote:
I thought the whole idea behind PEAP was that every entity gets its own private key.
No. Every entity gets a unique session (WEP) key. This is unrelated to the private/public key previously mentioned. |
|
|
--------------------------------------------------------------------------------
I thought the whole idea behind PEAP was that every entity gets its own private key.
--------------------------------------------------------------------------------
No. Every entity gets a unique session (WEP) key. This is unrelated to the private/public key previously mentioned.
Any 802.1x based authentication protocol will generate a unique session key (or PMK in the WAP environment). For example, LEAP will do the same. The difference between LEAP and PEAP is that in PEAP the server-side authentication is performed over a secure tunnel. In LEAP, MD4 cache is used instead, which is less secure. If the same public key is used by everyone who installed tinyPEAP, than this benefit is no longer there. Incidentally, in PEAP, the client doesn't authenticate the server over a secure tunnel; the server authenticates the client. The client authenticates the server using one of non-PKI based 802.1x methods. It is only in EAP-TLS that the client and the server authenticate each other using two secure tunnels. This means that every client has to have a unique private key. |
|
| reply to c33v33
So, is my wireless security secure at all?
WEP keys are not secure, which has been proven in the past. (That's why TinyPEAP people say that it doesn't make any sense to use a 128-bit WEP key -- it is just as crackable as a 64-bit key but adds overhead). TinyPEAP with WEP rotates your key every 5 min (as you have found out). This makes it more secure than static WEP, but still not completely secure. If you want to be absolutely sure your communication is secure, use WPA TKIP (like they suggest).
It all depends on the environment you are in. If you are talking about a home office, your security level is probably adequate. If this is a business with some sensitive information, I would say that a dynamic WEP key is not secure enough. By the way, tinyPEAP will not add any security in the authentication process that real PEAP with unique private keys for every networks adds. So, it is quasi PEAP. However, it enables you to use WPA TKIP, which relies on both the RADIUS server and the client generating a unique WPA Pair-wise Master Key (PMK) for every client-server pair. Without a RADIUS server, WPA can only use a static Pre-shared Key (WPA-PSK). WPA-PSK is the same for every client. Should the WPA-PSK be compromised, every client will have to be re-keyed.
So, decide for yourself. If you are paranoid, buy an adapter that supports WPA-TKIP with PEAP. Again, tinyPEAP uses the PEAP authentication method to enable WPA TKIP with a unique dynamic PMK, but it doesn't make the authentication process itself more secure because everyone uses the same public key, and therefore, every Access Point that runs this software is using the same private key. Hence, the client doesn't know whether it is talking to a legitimate AP or a hacker. The good news is that the username/password are not sent in clear text but are hashed. So, it is very difficult for a hacker to guess user's credentials. However, the user credentials are open to a dictionary attack. So, even when using tinyPEAP, username/password shouldn't be weak. |
|
1 edit | reply to sirozha
quote:
Incidentally, in PEAP, the client doesn't authenticate the server over a secure tunnel; the server authenticates the client.
The client and server set up a TLS connection. Just like setting up an SSL or TLS connection with a WEB server the RADIUS server (or TinyPEAP in this case) authenticates itself to the client. The client uses the server's certificate to verify that the server is who it claims to be. (In reality the server proves that it has the private key corresponding to the public key in the certificate. This is how it authenticates itself.) Once the secure TLS channel has been setup the clients "logs in". It looks like TinyPEAP supports MS-CHAPv2 for this "log in".
As I said, since all TinyPEAP installations use the same private key and certificate I cannot authenticate my TinyPEAP server. All TinyPEAP installations will have the same private key So I know I am connecting to a TinyPEAP server (or to a server which copied the private key from a TinyPEAP server) but I do not know which one. |
|
DSLrgmPremium,MVM
join:2002-08-22
Oak Park, MI | reply to c33v33
In the windows version there are two files:
WaCert.pem and WaKey.pem
If these are really in PEM format, they would be easy to replace.
Also there is a peapd.conf that includes the RADIUS shared Secret. So it can be changed too.
So it would seem that for Windows, they are positioned to upgrade their level of security. They only need the firmware version to include interfaces to change these or download separate files.
As far as them being so secure with WEP becuase they change the STA key every 5 min:
I ASSuME there is a standard way to designate which keyID to install during a reauth. PEAP does not 'tell' the STA, nor does RADIUS-AccessAccept 'tell' the AP which keyID to use, so Interoperablity MAY be at issue if the AP is not Linksys and the STA is not XP.
The AP controls rollovers for the broadcast/multicast group key, and since file and print sharing between wireless clients tend to use broadcast, this traffic may be easy to attack. |
|
| reply to michaelr7
--------------------------------------------------------------------------------
Incidentally, in PEAP, the client doesn't authenticate the server over a secure tunnel; the server authenticates the client.
--------------------------------------------------------------------------------
The client and server set up a TLS connection. Just like setting up an SSL or TLS connection with a WEB server the RADIUS server (or TinyPEAP in this case) authenticates itself to the client. The client uses the server's certificate to verify that the server is who it claims to be.
I'm sorry, but the word "authentication" means verification of entity's credentials. In PEAP, the client receives the server's public key together with the authentication challenge. The client doesn't have the public key of the server prior to the authentication. But it does have the public key of the Certification Authority. The server's public key is signed with the Certification Authority's private key. So, if the client trusts the Certification Authority, it accepts the server's public key as a trusted key. Then, using this public key, the client encrypts it's response to the authentication challenge. The server uses its private key to decrypt the client's response. The client's response contains its credentials (username/password) in a hashed form. When the server receives the authentication response from the client and decrypts it, the server calculates the same hash and compares it to the received hash. If the values match, the server authenticates the client. In PEAP, the client also authenticates the server, but it does not happen over a secure tunnel. A number of other EAP methods can be used for this. In EAP-TLS, however, both the server-side authentication and the client-side authentication are done over secure tunnels -- there are two tunnels created. One is with the server's private key, and the other one is with the client's private key. |
|
DSLrgmPremium,MVM
join:2002-08-22
Oak Park, MI | said by sirozha:
I'm sorry, but the word "authentication" means verification of entity's credentials. In PEAP, the client receives the server's public key together with the authentication challenge. The client doesn't have the public key of the server prior to the authentication. But it does have the public key of the Certification Authority.
I *TEACH* a cryptography class, and unfortunately, was involved in developing TLS. That said both are right. SSL/TLS has all too many methods for validation.
TYPICALLY, the server sends its cert and that is validated per X.509 path validation rules. THEN the challenge, signed with the server's private key can be validated.
But SSL/TLS ALSO supports the case where the client already has the server cert and already has establish trust of that cert (through whatever mechanism). This cert, already on the client, is used to validate the challenge. This option in SSL is there to save bandwidth, but has many other applications. It is used here, in many PEAP deployments, to already have the server cert on the station.
I should point out that EDI in S/MIME over HTTP (still an Internet Draft of the EDIINT wg) is being MANDATED by Wal*Mart; every supplier MUST be using this by the end of the year. And Wal*Mart's methodology is to exchange server certs through a trusted channel (like a purchasing agent receiving it on diskette from the supplier). No path validation needed to slow the deployment of secure EDI.... |
|
DaMaGeINCThe Lan ManPremium
join:2002-06-08
Greenville, SC
kudos:2 | What the hell are you talking about? The poster just asked if hes secure enough. And yes he is. Long as thier is some form of encryption, no one will bother him. And passive scanner will ignore him and keep driving. Please end this tech talk.
--
inc.ath.cx
Have a Networking problem or question? Stop by the Networking Forum and let us help you. |
|
 adsldudePremium,Ex-Mod 2003-9
join:2000-11-10
Colorado
kudos:1
1 edit | said by c33v33:
Is this network secure? I'm paranoid about wireless thieves!!
Can someone rate the "secureness" of each type of wireless security i.e. AES>WEP>MAC filter?
Also, does anyone have that link from Tom's Networking that shows the overhead for each type of wireless encryption?
said by DaMaGeINC:
The poster just asked if hes secure enough.
The original poster asked if he was secure enough AND for wireless technology security ratings AND wireless encryption overhead.
Those questions justify the thread's technical responses. As a self-professed war-driver would you like to comment on the other 2 questions? Your viewpoint may help shed light on the importance of the questions.
--
My other passion is mountain biking. Info on the Colorado based Front Range Mountain Bike Patrol - FRMBP can be found at:
»frmbp.homeip.net |
|
c33v33
join:2003-10-14
Chicago, IL | reply to c33v33
thank you for all the responses. ALL of them were helpful. I am very interested in the "workings" of wireless security, as I don't know much about it. 
So I guess I can assume I'm @ least a little safe on the wireless side? If a hacker wanted to get in, would it be hard? These responses seem to indicate some failure/holes in the authentication process. My network is not an office or business, just a regular home.
But hey still better than regular WEP right? 
But how bout compared to WPA-PSK? |
|
DSLrgmPremium,MVM
join:2002-08-22
Oak Park, MI | said by c33v33:
thank you for all the responses. ALL of them were helpful. I am very interested in the "workings" of wireless security, as I don't know much about it.
If you want to read up on it from the technical side, get Edney/Aurbaugh's book: "Real 802.11 Security"
Jon is one of the old-timers with 802.11 and Bill is a well-established security researcher, now a prof at U of Maryland (he wrote the original paper on attacks on 802.1X)
quote:
So I guess I can assume I'm @ least a little safe on the wireless side?
Fortunately this is not sex where it is not possible to get a little pregnent, or get a little sick.
It all depends on risk models.
quote:
If a hacker wanted to get in, would it be hard? These responses seem to indicate some failure/holes in the authentication process. My network is not an office or business, just a regular home.
TimyPEAP, as it stands right now is easy to spoof a rogue AP to act as a MITM attacker. Their plans, as stated, will address this in time.
Depending on how the AP is managing the Broadcast WEP key, you are still open to attacks on that, and any file and print services between two wireless devices or from wired to wireless will be using that key, and not your per-station key.
Also, if someone were to bother to implement one of the advanced WEP attacks, Malice could get your station key in about 4000 packets. Not much for some streaming WEB apps.
quote:
But hey still better than regular WEP right?
Dah, well of course. But is it enough for your risk model?
quote:
But how bout compared to WPA-PSK?
WPA manages the broadcast key properly. There are no known attacks against TKIP. But if you choose a weak PSK, you are worst off than with WEP. |
|
c33v33
join:2003-10-14
Chicago, IL
2 edits | reply to c33v33
Well, all these talks about how WPA is so much better got me back into finding a solution about how to get my WMP11v4 to work with WPA AES. I've tried before to no avail. The official Linksys drivers don't work with WPA.
So I found what chipset these WMP11v4's are made of. Turns out they are Inprocomm chipsets, more specifically IPN2120. They also have the drivers for the 2120 on their website:
»www.inprocomm.com.tw/products02.htm
Now I got WPA AES working with no hitch. I didn't choose to go with WPA-PSK. Instead, I got tinyPEAP to work with WPA AES Radius.
I guess my question now is, WPA-PSK? Or WPA Radius on the tinyPEAP?
Thanks guys! |
|
| reply to sirozha
quote:
I'm sorry, but the word "authentication" means verification of entity's credentials.
However my sending you a certificate signed by a CA proves nothing. You may validate the certificate but it certainly doesn't authenticate me. Authentication occurs when you use the private key to create a hash of some data and I use the public key to recover the original data.
quote:
So, if the client trusts the Certification Authority, it accepts the server's public key as a trusted key.
It accepts the certificate a belonging to whatever the subject field indicates (that is what a CA certifies - the public key belongs to that subject). It then extracts the public key and uses it to authenticate the peer. In theory no-one but the subject entity of the certificate has the private key. This is the flaw in TinyPEAP. You may authenticate the server but every TinyPEAP server has the same private key. |
|
| I don't think that what you call "authentication" is authentication. Authenticaton is validation of username/password. This can be done without a secure tunnel (like in LEAP) or via a secure tunnel like in PEAP. Since there's only a one-way tunnel established in PEAP, this tunnel is used by the server to authenticate the client's username/password. The client then challenges the server for its credentials using another EAP method. So, only the server-side authentication is done via a secure tunnel. But if you want to call the secure tunnel itself "authentication", go ahead. You have already mentioned that since every TinyPEAP server uses the same private key, anyone who owns the same kind of router can use it as a rogue AP, and the client won't know it's talking to an attacker when it is sending the hash of its username/password in response to the attacker's challenge. However, the authentication will not be successful because the rouge AP will not know the actual user's credentials (username/password), and it can't derive them from a hash that it receives from the client. So, the only way this network can be broken into is by a dictionary attack, which means that TinyPEAP is no more secure than LEAP. I understand why they decided to use PEAP instead of LEAP, though. The reason is that Windows XP's supplicant supports PEAP, but doesn't support LEAP. Most SOHO card manufacturers don't support LEAP either. Therefore, almost anyone can use 802.1x authentication with TinyPEAP, using the standard PEAP engine. |
|
DSLrgmPremium,MVM
join:2002-08-22
Oak Park, MI | reply to c33v33
said by c33v33:
Now I got WPA AES working with no hitch. I didn't choose to go with WPA-PSK. Instead, I got tinyPEAP to work with WPA AES Radius.
I guess my question now is, WPA-PSK? Or WPA Radius on the tinyPEAP?
Not much of a contest: WPA Radius with TinyPEAP.
Read my paper at ICSAlabs about the risks with WPA-PSK.
Your risk with TinyPEAP is, IMHO, a temporary one. They have one cert and one shared secret for everyone. This will change at some reasonable time soon. And as I indicated, if you use the Win32 version, you can change at least the shared secret, if not the cert until they get a UI set up on the Linksys.
With a single cert and the common shared secret, it is very easy to launch the PEAP MITM attack. |
|
