Opinion on Israeli espionage plot

2005-06-04 Thread Hagai Bar-El

List,

In the following link is an opinion about the espionage act discovered in 
Israel a week ago.
In short: This case is probably one of dozens, but the only one that was 
discovered probably due to three non-typical mistakes that were done.


http://www.hbarel.com/Blog/entry0004.html

Hagai.

---
Hagai Bar-El - Information Security Analyst
T/F: 972-8-9354152 Web: www.hbarel.com


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Papers about Algorithm hiding ?

2005-06-04 Thread Ian G
On Thursday 02 June 2005 13:50, Steve Furlong wrote:
 On 5/31/05, Ian G [EMAIL PROTECTED] wrote:
  I don't agree with your conclusion that hiding algorithms
  is a requirement.  I think there is a much better direction:
  spread more algorithms.  If everyone is using crypto then
  how can that be relevant to the case?

 This is so, in the ideal. But if everyone would only... never seems
 to work out in practice. Better to rely on what you can on your own or
 with a small group.

The number of people who are involved is actually quite
small if you think it through.  It's more a shift in attitude that
is the barrier, not a large number of people who have to
be sold.

GPG is an application that could be delivered by default
in all free OSs.  BSD is more or less installed automatically
with SSH installed.  Linux machines that are set up are
also generally set up with SSH.

From there it isn't a large step conceptually to install GPG
in the base installs.  Start with the BSDs (because they
understand security) and Linux (because they understand
cool).

It's also not a large step to add a special hook into SSH
and browsers to add a simple file encryption utility.  Just
like OpenPGP's secret key mode.  It doesn't have to be
good, it just has to be there.  A lot of machines have OpenSSL
in them (this is how we get easy access to SHA1).  Can we
add a simple file encrypt to that?

Once all the Unixen have these, the next step is to encourage
a little usage...  All you need to do is have one person that
you communicate with like your brother or sister for the fun
of doing some crypto chat, and it now becomes a regular
*non-relevant* issue.  All we need to do is to encrypt and
protect one file and encryption becomes easy.

 In response to Hadmut's question, for instance, I'd hide the crypto
 app by renaming the executable. This wouldn't work for a complex app
 like PGP Suite but would suffice for a simple app. Rename the
 encrypted files as well and you're fairly safe. (I've consulted with
 firms that do disk drive analysis. From what I've seen, unless the
 application name or the data file extensions are in a known list, they
 won't be seen. But my work has been in the realm of civil suits,
 contract disputes, SEC claims, and the like; the investigators might
 be more thorough when trying to nail someone for kiddie porn.)

Right.  If they find any evidence of information hiding
other than a boring OpenPGP install that is as common
as crazy frog mp3s then that's what I'd call highly relevent
evidence.  That would make matters worse for the particular
case at hand.

Information hiding is real sexy.  I wouldn't recommend it
for anyone who isn't really sure of their situation, and is
willing to understand that if he gets caught with it, he's
dead.

 Or use another app which by the way has crypto. Winzip apparently has
 some implementation flaws
 (http://www.cse.ucsd.edu/users/tkohno/papers/WinZip/ ) but a quick
 google doesn't show anything but brute force and dictionary attacks
 against WinRar.

Certainly using another app is fine.  What would be more
relevant to the direct issue is that it becomes routine to
encrypt and to have encryption installed.  See the recent
threads on where all the data is being lost - user data is
being lost simply because the companies don't protect
it.  Why aren't they protecting it?  Because there are no
easy tools that are built in to automatically and easily
protect it.

The picture here is becoming overwhelmingly clear - in order
to protect users we should be employing as much crypto as
we can openly, opportunistically, and easily.  Anything that
holds back from users protecting their data is a bad, and
anything that moves them forward in protecting their data
is a good.

iang
-- 
Advances in Financial Cryptography:
   https://www.financialcryptography.com/mt/archives/000458.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-04 Thread Dan Riley
Matt Crawford [EMAIL PROTECTED] writes:
 On Jun 3, 2005, at 11:55, Perry E. Metzger wrote:
  2) They also have a way of forcing pairing to happen, by impersonating
 one of the devices and saying oops! I need to pair again! to the
 other.
 
 Do the devices then pair again without user intervention, re-using the
 PIN that paired them initially?

In the notes for section 5, they say

If the attack is successful, the Bluetooth user will need to enter
the PIN again - so a suspicious user may realize that his
Bluetooth device is under attack and refuse to enter the PIN.

So no, it doesn't re-pair without intervention.

-dan

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [Clips] Paying Extra for Faster Airport Security

2005-06-04 Thread Anne Lynn Wheeler
one of the articles from a couple months ago about what happens if too 
many people shift into a priority queue. note that it is somewhat 
cheaper to let a few people to pay to go to the head of the screening 
line ... so that their queueing wait is reduced. It is a lot more 
expensive to install significantly more screening stations if you are 
planning on moving a large precentage of the people to the priority queue.


Frequent fliers' priority perks may lose value
http://www.marketwatch.com/news/story.asp?guid=%7B4CB9FEEC-C6A3-477E-BC79-7E465CDA9BBC%7Dsiteid=googledist=googlecbsReferrer=

an article about making the screening process (itself) significantly, 
rather than just re-arraigning the order that people go thru the 
screening process.


Design Build Contractor Emmanuel Cabrera Unveils Model for a New Airport 
Security and Screening Facility

http://www.kltv.com/Global/story.asp?S=2981723

some older stories about going to the head of the screening line

Orlando airport will allow frequent fliers to bypass screening
http://www.usatoday.com/travel/flights/2005-02-17-orlando-bypass_x.htm
OIA, TSA to launch first 'Private Sector Known Traveler Program'
http://orlando.bizjournals.com/orlando/stories/2005/02/14/daily37.html


lots of recent stories about going to the head of the screening line.

Voluntary Security ID to Debut in Florida
http://www.rednova.com/news/general/153608/voluntary_security_id_to_debut_in_florida/
Voluntary Security ID to Debut in Florida
http://www.sierratimes.com/rss/newswire.php?article=/news.yahoo.com/news?tmpl=storyu=/ap/20050603/ap_on_re_us/private_security_passtime=1117836210feed=us
Voluntary Security ID to Debut in Florida
http://www.durantdemocrat.com/articles/2005/06/03/ap/hitech/d8agc8180.txt
Voluntary security ID to debut in Florida
http://www.bradenton.com/mld/bradenton/11808773.htm
Voluntary security ID to debut in Florida
http://www.mercurynews.com/mld/mercurynews/news/11808773.htm
Orlando airport first tester of quick-pass voluntary biometric ID
http://www.jacksonville.com/tu-online/apnews/stories/060305/D8AGBC3G1.shtml
Orlando airport to allow use of $80 security ID
http://www.chron.com/cs/CDA/ssistory.mpl/business/3210249
Voluntary Security ID to Debut in Florida
http://wireservice.wired.com/wired/story.asp?section=BreakingstoryId=1043759
Firm's system lets frequent fliers speed through airport's security
http://www.philly.com/mld/inquirer/news/nation/11811618.htm
Passes put fliers in the fast lane
http://www.sun-sentinel.com/business/local/sfl-zairport04jun04,0,939657.story?coll=sfla-business-headlines
Skipping security checks
http://www.mercurynews.com/mld/mercurynews/business/11814661.htm
Bio ID may make airport security easy
http://www.harktheherald.com/modules.php?op=modloadname=Newsfile=articlesid=56599mode=threadorder=0thold=0
Transport Deptt. Wants the Airline Passenger Information
http://archives.moneyplans.net/frontend204-verify-7796.html
Airport fast lanes to get test
http://www.sptimes.com/2005/06/04/Worldandnation/Airport_fast_lanes_to.shtml

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: What happened with the session fixation bug?

2005-06-04 Thread Ben Laurie

James A. Donald wrote:

--
James A. Donald:

PKI was designed to defeat man in the middle attacks 
based on network sniffing, or DNS hijacking, which 
turned out to be less of a threat than expected.


However, the session fixation bugs 
http://www.acros.si/papers/session_fixation.pdf make 
https and PKI  worthless against such man in the 
middle attacks.  Have these bugs been addressed?



On 20 May 2005 at 23:21, Ben Laurie wrote:

Do they exist? Certainly any session ID I've ever had 
a hand in has two properties that strongly resist 
session fixation:


a) If a session ID arrives, it should already exist in 
the database.


b) Session IDs include HMACs.



The way to beat session fixation is to issue a 
privileged and impossible to predict session ID in 
response to a correct login.


If, however, you grant privileges to a session ID on the 
basis of a successful login, which is in fact the usual 
practice, you are hosed. The normal programming model 
creates a session ID, then sets variables and flags 
associated with that session ID in response to forms 
submitted by the user.  To prevent session fixation, you 
must create the session ID with unchangeable privileges 
from the moment of creation.


Why? I suspect you are thinking of an attack other than session 
fixation. How does your attack work?


Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: What happened with the session fixation bug?

2005-06-04 Thread James A. Donald
--
James A. Donald wrote:
  The way to beat session fixation is to issue a 
  privileged and impossible to predict session ID in 
  response to a correct login.
 
  If, however, you grant privileges to a session ID on 
  the basis of a successful login, which is in fact 
  the usual practice, you are hosed. The normal 
  programming model creates a session ID, then sets 
  variables and flags associated with that session ID 
  in response to forms submitted by the user.  To 
  prevent session fixation, you must create the 
  session ID with unchangeable privileges from the 
  moment of creation.

Ben Laurie wrote:
 How does your attack work?

Your business about MACS and stuff was to prevent the 
adversary guessing the users session ID.  With session 
fixation, the adversary does not try to guess the 
legitimate users session ID, instead he fools the 
browser of the legitimate user into using the 
adversary's session ID.

Adversary accesses web site as if about to log in, gets
a session ID.  Then supplies false information to 
someone else's browser, causes that browser on some one 
else's computer to use that session ID.  Someone else 
logs in with hacker's session ID, and now the adversary
is logged in. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 fUQA7VMYJROi7AAUHD8ZmEHReDprBvrg3u3cL2VI
 4NzEz9SAfaOzb7GhsAkM//vmMQKDsrdLEInHLumm3


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-04 Thread Thomas Lakofski
Perry E. Metzger wrote:
 Matt Crawford [EMAIL PROTECTED] writes:
 
On Jun 3, 2005, at 11:55, Perry E. Metzger wrote:

2) They also have a way of forcing pairing to happen, by impersonating
   one of the devices and saying oops! I need to pair again! to the
   other.

Do the devices then pair again without user intervention, re-using the
PIN that paired them initially?
 
 
 That is my understanding. Ugly, isn't it?

The paper addresses countermeasures; it would appear that the original PIN is
not stored for reuse in most (any?) implementations, but that there is an option
to use a PIN every time the devices are connected, which would expose this risk:

6 Countermeasures
 This section details the countermeasures one should consider when using a
Bluetooth device. These countermeasures will reduce the probability of being
subjected to both attacks and the vulnerability to these attacks.

 Since Bluetooth is a wireless technology, it is very difficult to avoid
Bluetooth signals from leaking outside the desired boundaries. Therefore, one
should follow the recommendation in the Bluetooth standard and refrain from
entering the PIN into the Bluetooth device for pairing as much as possible. This
reduces the risk of an attacker eavesdropping on the pairing process and finding
the PIN used.

 Most Bluetooth devices save the link key (Kab) in non-volatile memory for
future use. This way, when the same Bluetooth devices wish to communicate again,
they use the stored link key. However, there is another mode of work, which
requires entering the PIN into both devices every time they wish to communicate,
even if they have already been paired before. This mode gives a false sense of
security! Starting the pairing process every time increases the probability of
an attacker eavesdropping on the messages transferred. We suggest not to use
this mode of work.

 Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers use a 4
digit PIN and supply it with the device. Obviously, customers should demand the
ability to use longer PINs.

-thomas

--
Thomas Lakofski +44 70 9228 8229
'Reality is that which, when you stop believing in it, doesn't go away' --PKD
gpg: 1024D/81FD4B43  2B72 53DB 8104 2041 BDB4  F053 4AE5 01DF 81FD 4B43
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-04 Thread Olle Mulmo


On Jun 4, 2005, at 14:12, Thomas Lakofski wrote:

Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers 
use a 4 digit PIN and supply it with the device. Obviously, customers 
should demand the ability to use longer PINs.


Correction: Most manufacturers hardcode the 4-digit PIN to . It has 
been known for some time that those gadgets need to be paired in an 
Faradayic environment: if I recall correctly, a paper being presented 
on this at the RSA conference ~2001 or so.


The forced re-pairing vulnerability is news to me. It makes me very 
concerned about Bluetooth keyboards...


/O


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-04 Thread Thomas Lakofski
Olle Mulmo wrote:
 On Jun 4, 2005, at 14:12, Thomas Lakofski wrote:

Wrote?  Well, quoted...

 Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers
 use a 4 digit PIN and supply it with the device. Obviously, customers
 should demand the ability to use longer PINs.

 Correction: Most manufacturers hardcode the 4-digit PIN to . It has
 been known for some time that those gadgets need to be paired in an
 Faradayic environment: if I recall correctly, a paper being presented on
 this at the RSA conference ~2001 or so.

For some values of 'most.'  This would cover mice, keyboards and wireless
headsets.  My MS Bluetooth mouse doesn't need any PIN or even encryption to
connect...  I've yet to see a Bluetooth-capable telephone with a fixed PIN; I
would doubt that the number of shipped BT mice, keyboards and headsets exceeds
the number of BT-capable telephones in existence.

 The forced re-pairing vulnerability is news to me. It makes me very
 concerned about Bluetooth keyboards...

Your attacker would need to keep a device live and in the neighbourhood of your
Bluetooth keyboard to perform a mitm attack; I'd be more worried about the
non-Bluetooth wireless keyboards out there.

-thomas

ps, it's a little ironic that a post to a cryptography list has its digital
signature stripped before reaching the list, no?

--
Thomas Lakofski +44 70 9228 8229
'Reality is that which, when you stop believing in it, doesn't go away' --PKD
gpg: 1024D/81FD4B43  2B72 53DB 8104 2041 BDB4  F053 4AE5 01DF 81FD 4B43
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]