Re: ATM machine security

2005-02-22 Thread Alex Alten
You may want to look at US Patents 4,268,715 and 4,268,715.
I believe these are among the core group of ATM patents.
- Alex
At 09:58 AM 2/17/2005 +0100, Lee Parkes wrote:
Hi,
I'm working on a project that requires a benchmark against which to judge
various suppliers. The closest that has similar requirements is the ATM
industry. To this end I'm looking for any papers, specifications or published
attacks against ATM machines and their infrastructure. I'm also looking 
for what
type of networks they use and the crypto they use to protect comms.
Also any standards would be good that the ATM industry has to adhere to.

Thanks,
Lee
--
--
[EMAIL PROTECTED] DOC #25 GLASS #136
I Need A Reason To Stand Up And Fight
Need To Believe What I See - The Silver Drop - Mnemic
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
--
- Alex
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: draft paper: Deploying a New Hash Algorithm

2005-08-04 Thread Alex Alten

Steve,

At 05:34 PM 7/29/2005 -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Alex Alten 
write

s:
At 08:12 AM 7/25/2005 -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Alex Alten
write
s:
 Steve,
 
 This also seems to be in conjunction with the potential switch over from
 RSA et al. to
 ECC for PKI, etc.
 

Yes, Eric and I have been talking about that, and we'll add some
discussion of that to the next version of the paper.

Variable output is really needed too, say 16, 32, 64, 128, 256 and 512 bits.
And on the wishful side, the ability to optimize compression across
multiple CPUs.


That's completely orthogoal to what the paper is about.  We're talking
about how to convert to *any* new hash algorithm; we're not concerned
with which is chosen.  (I confess, though, that hash outputs of less
than 128 bits don't strike me as cryptographically useful except for
HMAC and the like.)


Sorry for going off on a tangent.

Actually 32 (or even 16) bits is really useful for retrofitting old 
insecure protocols where you
don't want to alter the header size, you only need access control, and the 
packets only exist

for less than 100 msecs.

- Alex

--

- Alex Alten


[Moderator's note: I have to strongly disagree. 16 bits is rarely, if
ever, of any use in authentication in a modern system. Even if you
think something can't live long enough to be spoofed, it usually can,
and as it turns out, attackers are often cleverer than protocol
designers. Crypto is too brittle to play such games with it. --Perry]
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: When people ask for security holes as features

2005-08-19 Thread Alex Alten

At 07:37 PM 8/18/2005 +1200, Peter Gutmann wrote:

Raymond Chen's blog has an interesting look at companies trying to bypass
Windows XP's checks that a driver has been WHQL-certified:


These guys are amateurs.  There are registery flags and COM functions that
will prevent the dialogs from popping up.  I've done it myself when developing
a driver and having to reinstall it dozens of times each day.  I've even 
disabled
XP's personal firewall to install stuff that needed to use a private port 
during
install. This was for a appliance, where we controlled the OS version, 
hardware,

etc.  So any updates to the OS we validated before allowing the user to patch
the appliance.

As a small firm we couldn't afford both the time or money to go through
Microsoft every time we updated a driver.  For other firms not using the
appliance approach to shipping software, probably thay are trying to reduce
support costs, which is not unreasonable these days.

- Alex
--

- Alex Alten


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


Re: How ATM fraud nearly brought down British banking

2005-10-24 Thread Alex Alten

Is there any comparable fraud with the USA ATM system in recent decades?
I've only heard of this type of wholesale fraud in Europe or in pre-1980 USA.

- Alex

At 01:58 AM 10/22/2005 -0400, R.A. Hettinga wrote:


--- begin forwarded text


 Date: Sat, 22 Oct 2005 01:58:34 -0400
 To: Philodox Clips List [EMAIL PROTECTED]
 From: R.A. Hettinga [EMAIL PROTECTED]
 Subject: How ATM fraud nearly brought down British banking

 http://www.theregister.co.uk/2005/10/21/phantoms_and_rogues/print.html



--

- Alex Alten


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


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-26 Thread Alex Alten

At 06:09 PM 2/24/2006 +0100, Ian G wrote:

Steven M. Bellovin wrote:

Certainly, usability is an issue.  It hasn't been solved because there's 
no market for it here; far too few people care about email encryption.


Usability is the issue.  If I look over onto
my skype window, it says there are 5 million
or so users right now.  It did that without
any of the hullabaloo of the other systems,
and still manages to encrypt my comms.  By
some measures it is the most successful crypto
system ever.


Actually the usability issue has been solved elsewhere too.  We did it over 
at TriStrata
before the firm crashed in 1998.  We allowed the system security officer to 
select the
default cipher to use in sending emails (DES, 3DES, Blowfish, RC4, etc.). 
The receiver
could use any cipher for decrypting incoming email. A sys admin installed 
some filter
software into the email client, and except for an initial login dialog (and 
we even simplified
that by hooking the OS login dialog), the user never had to do anything 
further.  The local
auth keys that he received during enrollment were encrypted with his 
password on a small

floppy disk, or could be installed on the hard drive automatically.

Last I heard (early 2005) one system was operational over in the nuclear 
engineering
department at Ohio State (for DOE work?).  Of course one old system rack in 
the

dusty corner of a school building does not a market make.

- Alex

--

- Alex Alten


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


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-28 Thread Alex Alten

At 05:12 PM 2/26/2006 +, Ben Laurie wrote:

Alex Alten wrote:
 At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
 Ed Gerck wrote: We have keyservers for this (my chosen technology
 was PGP). If you liken their use to looking up an address in an
 address book, this isn't hard for users to grasp.

 I used PGP (Enterprise edition?) to encrypt my work emails to a
 distributed set of members last year.  We all had each other's public
 keys (about a dozen or so).

 What I really hated about it was that when [EMAIL PROTECTED] sent me
 an email often I couldn't decrypt it.  Why?  Because his firm's email
 server decided to put in the FROM field [EMAIL PROTECTED].
 Since it didn't match the email name in his X.509 certificate's DN it
 wouldn't decrypt the S/MIME attachment. This also caused problems
 with replying to his email.  It took us hours, with several
 experimental emails sent back and forth, to figure out the root of
 the problem.

 No wonder PKI has died commercially and encrypted email is on the
 endangered species list.

I trust you don't think this is a problem with PKI, right? Since clearly
the issue is with the s/w you were using.


I place the blame squarely on X.509 PKI.  The identity aspect of it is all 
screwed up.

No software implementation can overcome such a fundamental architectural flaw.

- Alex


--

- Alex Alten


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


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-03-08 Thread Alex Alten

At 05:58 AM 3/3/2006 +, Ben Laurie wrote:

[EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
 Alex Alten wrote:
 At 05:12 PM 2/26/2006 +, Ben Laurie wrote:
 Alex Alten wrote:
 At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
 Ed Gerck wrote: We have keyservers for this (my chosen
 technology was PGP). If you liken their use to looking up an
 address in an address book, this isn't hard for users to grasp.

 I used PGP (Enterprise edition?) to encrypt my work emails to
 a distributed set of members last year.  We all had each
 other's
 public keys (about a dozen or so).

 What I really hated about it was that when [EMAIL PROTECTED] sent
 me an email often I couldn't decrypt it.  Why?  Because his
 firm's email server decided to put in the FROM field
 [EMAIL PROTECTED]. Since it didn't match the email name
 in his X.509 certificate's DN it wouldn't decrypt the S/MIME
 attachment. This also caused problems with replying to his email.
 It took us hours, with several experimental emails sent back and
 forth, to figure out the root of the problem.

 No wonder PKI has died commercially and encrypted email is on the
  endangered species list.
 I trust you don't think this is a problem with PKI, right? Since
 clearly the issue is with the s/w you were using.
 I place the blame squarely on X.509 PKI.  The identity aspect of it
 is all screwed up. No software implementation can overcome such a
 fundamental architectural flaw.
 OK - I'll bite - why does the sender's identity have any impact on the
 recipient's ability to decrypt?

 Because the software needs a unique ID/name to find the correct
 key to use. In practice (corporate) users can have multiple email
 names, see my reply to Peter Gutman.  This is not the fault of
 the email architecture, which has been working fine for 30-40
 years, but the fault
 of the X.509 architecture trying to piggyback on an address/name
 space that is not designed with security/cryptography
 considerations in mind.
 I have to admit to not being familiar with S/MIME, but the usual
 practice is to identify the signing key in the signature. Certainly this
 is what OpenPGP does. Its also kinda weird to refuse to decrypt just
 because the signature can't be verified.


 How does OpenPGP identify the signing key in the incoming email's 
signature?


Here's the output of one of the example programs in OpenPGP:SDK
(http://openpgp.nominet.org.uk/), showing the structure of an OpenPGP
signed file. I trust it is self-explanatory.


Assuming this file is attached to an incoming email message, how does the
receiver's email software match the Signer ID (= 0x8337FE6485F4ED64) to
a X.509 cert in his local cache that is associated with the email sender's name
(= [EMAIL PROTECTED])?


--

- Alex Alten


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


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-03-08 Thread Alex Alten

At 03:13 AM 3/6/2006 +1300, Peter Gutmann wrote:


Basically our customer required us to encrypt any team communications. So we
used PGP with email.  I know the body of the email was encrypted, and I
believe attachments were too.  The certs were used to automate the
decryption.  Basically the PGP plugin would check the incoming mail's sender
email name and try to find a local cert that had the same email name in it.

Hmm, that sounds like broken software then, since the (probabilistically)
unique keyID to locate the appropriate decryption or signature verification
key is included in the message/signature - you never have to look at the From:
address, and indeed trying to use it for key lookups would be a recipe for
disaster because of the problems you pointed out.


RFC 3280 states that an end entity's subject key id SHOULD be included. It is
not a MANDATORY extension field, see section 4.2.1.2.  So the software is
not technically broken.

Since the key id is derived from the raw public key itself,  doesn't that 
defeat

the purpose of automatically authenticating that the encrypted email is really
from [EMAIL PROTECTED]?  I'm assuming a naive email user on the receiver
side that never manually maps the key id to [EMAIL PROTECTED].  Most
general users sort of understand the email name format, it's a bit much to 
force
them to map a cryptic looking key id to it too.  Especially considering the 
user
might have dozens or hundreds of people on their mailing list.  Mapping 
mistakes

would be common.

I won't mention the questions regarding certificate revocaton vs user email 
name.

:-)

- Alex


--

- Alex Alten


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


Re: OpenSSL PKCS #7 supports AES SHA-2 ?

2006-10-08 Thread Alex Alten

After reading PKCS #1 v2 more closely and SHA-2 is not even in the specs,
therefore OpenSSL PKCS #7 functions won't support SHA-2.  This spec was
last updated in 1998.

PKCS Editor, is there a new update in progress by RSA Labs to incorporate
SHA-2 and AES?

Does OpenSSL implement PKCS #1 v2 or just v1.5?  If the latter then not even
SHA-1 is supported.

PKCS editor, is there any timeline as to when PKCS #7 will then be updated
with references to official OIDs, etc., for specifying SHA-2 and AES?

Dr. Ron Rivest, are you going to publish new message-digest IETF RFCs for 
SHA-1

and SHA-2?  (So that they can be referenced by an updated PKCS #7.)

Mr. Russ Housley, can you weigh in with what happening in the IETF WG security
area?  I know that Mr. Eric Rescorla is working on a new TLS v1.2 
draft.  Will this

be done/ratified soon?  I assume OpenSSL will incorporate this soon thereafter?

This mess with the MD5 and SHA-1 hashes is really starting to becoming a 
problem.
It's certainly impacting new development projects/products I'm involved 
with using

SSL and PKI certificates.  My customers are concerned about using MD5 and
SHA-1, and they don't want to keep paying for implementations repeatedly as 
the

standards catch up to reality.  Updating these various heavily used standards
quickly is quite important.

Sincerely (and thanks in advance for all of your replies),

- Alex


At 09:05 AM 10/6/2006 -0700, Alex Alten wrote:

Does anyone know if the OpenSSL PKCS #7 functions support AES and SHA-2?
(I assuming OpenSSL 0.9.7 or later.)

Thanks,

- Alex



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


Re: OpenSSL PKCS #7 supports AES SHA-2 ?

2006-10-12 Thread Alex Alten

Russ,

OK.  I found SHA-2 in RFC 4634 (only 3 months old), which refers back to 
FIPS 180-2.


But I reach a dead-end with PKCS #7 (now RFC 3852).  There's no support for 
SHA-2

algorithm types (RFC 3279). Also PKCS #1 (now RFC 3447) needs an update for
SHA-2 with RSA encryption (OIDs, etc.).

Did I miss something or do you need help in updating these, since I, and 
probably

others too, need them?

- Alex


At 01:19 PM 10/9/2006 -0400, Russ Housley wrote:
PKCS#7 has been turned over to the IETF for maintenance.  The most recent 
version is RFC 3852.  Since the protocol is more stable than the 
cryptographic algorithms, the algorithm discussion appear in separate RFCs.


TLS 1.2 is under development in the IETF.  It is being done in such a way 
that none of the ciphersuites that have already been defined need to be 
updated, including the ones that use AES and the SHA-2 family.


Russ


At 01:28 AM 10/7/2006, Alex Alten wrote:

After reading PKCS #1 v2 more closely and SHA-2 is not even in the specs,
therefore OpenSSL PKCS #7 functions won't support SHA-2.  This spec was
last updated in 1998.

PKCS Editor, is there a new update in progress by RSA Labs to incorporate
SHA-2 and AES?

Does OpenSSL implement PKCS #1 v2 or just v1.5?  If the latter then not even
SHA-1 is supported.

PKCS editor, is there any timeline as to when PKCS #7 will then be updated
with references to official OIDs, etc., for specifying SHA-2 and AES?

Dr. Ron Rivest, are you going to publish new message-digest IETF RFCs for 
SHA-1

and SHA-2?  (So that they can be referenced by an updated PKCS #7.)

Mr. Russ Housley, can you weigh in with what happening in the IETF WG 
security
area?  I know that Mr. Eric Rescorla is working on a new TLS v1.2 
draft.  Will this
be done/ratified soon?  I assume OpenSSL will incorporate this soon 
thereafter?


This mess with the MD5 and SHA-1 hashes is really starting to becoming a 
problem.
It's certainly impacting new development projects/products I'm involved 
with using

SSL and PKI certificates.  My customers are concerned about using MD5 and
SHA-1, and they don't want to keep paying for implementations repeatedly 
as the

standards catch up to reality.  Updating these various heavily used standards
quickly is quite important.

Sincerely (and thanks in advance for all of your replies),

- Alex


At 09:05 AM 10/6/2006 -0700, Alex Alten wrote:

Does anyone know if the OpenSSL PKCS #7 functions support AES and SHA-2?
(I assuming OpenSSL 0.9.7 or later.)

Thanks,

- Alex


--

Alex Alten
Alten Security Engineering, Inc.
[EMAIL PROTECTED]




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


Re: cellphones as room bugs

2006-12-04 Thread Alex Alten


At 10:21 AM 12/2/2006 -0500, Perry E. Metzger wrote:


Quoting:

   The FBI appears to have begun using a novel form of electronic
   surveillance in criminal investigations: remotely activating a
   mobile phone's microphone and using it to eavesdrop on nearby
   conversations.

   The technique is called a roving bug, and was approved by top
   U.S. Department of Justice officials for use against members of a
   New York organized crime family who were wary of conventional
   surveillance techniques such as tailing a suspect or wiretapping
   him.

http://news.com.com/2100-1029_3-6140191.html


Cellphones maintain contact with cell towers, so they can be roughly
tracked on the ground too, even when you are not talking.  With GPS
being embedded this may become much more accurate.

As an amusing aside, for a while someone was accidently calling my
land line with their cell phone.  You could hear them driving around, with
the usual car noises, and sometimes the radio on too. Occasionally I
heard them in conversation with someone else. This went on for months.

- Alex


--

Alex Alten
[EMAIL PROTECTED]



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


Re: gang uses crypto to hide identity theft databases

2006-12-22 Thread Alex Alten
I'm curious as to why the cops didn't just pull the plugs right away.  It 
would probably
take a while (minutes, hours?) to encrypt any significant amount of 
data.  Not to

mention, where is the master key? The guy couldn't have jumped up and typed
in a pass phrase to generate it in handcuffs? Even if it got erased, it's 
image could
be recovered from a disk or RAM.  My understanding is that even tamperproof 
cards

one can get keys from them with the right equipment from the right folks.

- Alex

At 02:51 AM 12/23/2006 +1300, Peter Gutmann wrote:

Jim Gellman [EMAIL PROTECTED] writes:
Well this just sucks if you ask me.
 According to the Crown Prosecution Service (CPS), which confirmed that
 Kostap had activated the encryption after being arrested, it would
 have taken 400 computers twelve years to crack the code.
Scales linearly, right?  4,800 computers'll get it in a year?

I don't think you can even apply that much analysis to it.  How exactly did
they come up with such a figure in the first place?  400 *what* computers?
TRS-80's?  Cray XT4's?  Does the encryption software come with a disclaimer
saying if you forget your password, it'll take 400 computers 12 years to
recover your data?  With that level of CPU power it sounds like it'd
something at the level of brute-forcing a 56-bit DES key (using a software-
only approach), which sounds like an odd algorithm to use if it's current
crypto software.  It sounds more like a quote for the media (or, more likely,
misreporting) than any real estimate of the effort involved.

Peter.

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


--

Alex Alten
[EMAIL PROTECTED]



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


SSL MITM attack vs wiretap laws question

2007-05-05 Thread Alex Alten
I have a question about the legality of doing a successful MITM attack 
against SSL
(server-side authentication only).  This is mainly a USA only 
question.  Although
Europe and Japan is of interest too.  This is not a CALEA or ETSI type of 
situation.


If the SSL connection is traversing an enterprise or a common carrier is it 
legal for
that party to perform a MITM against it in order to examine the encrypted 
information?


My reading of the US Federal wiretap laws seems to indicate that this is ok 
if one of the

following conditions exists:
1. The enterprise/carrier posts a notice that all SSL connections are 
subject to inspection.
2. The enterprise/carrier notifies one or both parties of the SSL 
connection that inspection

is taking place.
3. The enterprise/carrier examines the SSL to prevent 
DoS/DDoS/Worm/Phishing attacks

or to do QoS (load balancing, bandwidth shaping, etc).

I don't think wire fraud laws are involved, even though a properly signed 
yet fake X.509
PKI certificate is sent to the browser by the MITM enterprise/carrier 
pretending to be
the destination site in order to extract the encryption keys used to 
encrypt the

SSL connection.

Any lawyers out there who would know how to interpret US federal law regarding
this area?  (European/Japan, or other rule-of-law type countries are of 
interest too.)


Thanks,

- Alex
--

Alex Alten
[EMAIL PROTECTED]



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


Russian cyberwar against Estonia?

2007-05-18 Thread Alex Alten

This may be a bit off the crypto topic, but it is interesting nonetheless.

Russia accused of unleashing cyberwar to disable Estonia
http://www.guardian.co.uk/print/0,,329864981-103610,00.html

Estonia accuses Russia of 'cyberattack'
http://www.csmonitor.com/2007/0517/p99s01-duts.html

- Alex
--

Alex Alten
[EMAIL PROTECTED]

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


Re: A secure Internet requires a secure network protocol

2007-06-23 Thread Alex Alten

Lynne or Anne,

At 10:30 AM 6/22/2007 -0600, Anne  Lynn Wheeler wrote:

A secure Internet requires a secure network protocol
http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html



Actually I think we need a shadow Internet that is used only for security 
purposes (and is
fully encrypted).  It is sort of like the old SS7 signaling infrastructure 
of the phone network.
It doesn't need the same bandwidth, maybe 1/1000 or 1/10,000 as much.  It 
would use
strictly cryptographic protocols for identity  authentication and key 
management, etc..




one of the things seen in various of the SSL (authentication) vulnerabilities


SSL seems to be hanging by a thread, mainly the name to public key mapping
depends on how thorough the checking is done in to SSL vs application layers
inside of the web browser.  If this is hosed then unrestricted MITM is in 
the cards

sometime in the near future.

- Alex

--

Alex Alten
[EMAIL PROTECTED]



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


Re: New DoD encryption mandate

2007-08-17 Thread Alex Alten

At 04:02 AM 8/17/2007 -0700, =?UTF-8?Q?Ivan_Krsti=C4=87?= wrote:

On Aug 16, 2007, at 8:30 AM, Ali, Saqib wrote:

The other problem is that it lacks any centralized management. If you
are letting TPM manage your Bitlocker keys you still need a TPM
management suite with key backup/restore/transfer/migrate capabilities
in case your computer goes bad.


How so? If your computer goes bad, you need a *backup*. That's
entirely orthogonal to the drive encryption problem. Bitlocker uses
the TPM to provide assurance that your drive -- really, volume -- is
locked to your computer, and that the early boot environment hasn't
been messed with. When either check fails, you use the BitLocker
recovery password (either on a USB stick or entered manually) to
recover your data. This holds in the event that you take your drive
out and stick it in a different machine. In other words, the TPM is
not a single point of failure, so I don't understand why you think
you care about TPM backup/restore/transfer.


It depends on your requirements.  For a large numbers of computers
owned by a corporation/organization centralized key management
makes a lot of sense.  For a single user with a privately purchased
computer then the recovery password makes more sense.


The third problem is that it is software based encryption, which uses
the main CPU to perform the encryption.


Security is never free, but in 2007, we can afford the cycles. What's
a better use for them? Drawing semi-transparent stained glass window
borders?


Agreed, for most requirements.  Sometimes one may need to keep keys
in trusted hardware only.  The only real fly-in-the-ointment is that current
hash algorithms (SHA-1, SHA-2, etc.) don't scale across multiple CPU
cores (assuming you need integrity along with your privacy).

- Alex

--

Alex Alten
[EMAIL PROTECTED]



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


gauging interest in forming an USA chapter of IISP

2007-12-13 Thread Alex Alten


Would anyone on this list be interested in forming a USA chapter of the 
Institute

of Information Security Professionals (IISP, www.instisp.org)?

I'm finding it rather difficult to attend events, etc., that are only in 
London.


- Alex


--

Alex Alten
[EMAIL PROTECTED]



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


Re: gauging interest in forming an USA chapter of IISP

2007-12-14 Thread Alex Alten

Ali,

Sorry for the misunderstanding.  I'm not soliciting for new members.

If there happens to be anyone on this list who is an IISP member and lives 
in the USA
and would be interested in forming a chapter on this side of the Atlantic 
then I'd like to

work with them to establish it.

That's all.

- Alex

At 11:05 AM 12/13/2007 -0800, Ali, Saqib wrote:

How will this be any different from being a member of ISC2 or ISACA?
Why do we need to be a member of yet another organization?

saqib
http://www.quantumcrypto.de/dante/


On Dec 12, 2007 12:21 PM, Alex Alten [EMAIL PROTECTED] wrote:

 Would anyone on this list be interested in forming a USA chapter of the
 Institute
 of Information Security Professionals (IISP, www.instisp.org)?

 I'm finding it rather difficult to attend events, etc., that are only in
 London.

 - Alex


--

Alex Alten
[EMAIL PROTECTED]



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


Re: crypto class design

2007-12-26 Thread Alex Alten

At 06:48 PM 12/18/2007 -0800, Arshad Noor wrote:

While there are many different ways to approach encryption
and decryption of sensitive data, you may want to consider
how you plan to manage the encryption keys before you go
down this path.


This is prudent.  You should consider how to securely integrate
key management with other important components of a security
system, such as identity/authentication, policy adjudication
(policy enforcement should be the encrypt/decrypt itself) and
audit/logging.  Logging is usually very important in financial
firms.  You should also carefully think about how to support
revocation of users (i.e. preventing a revoked user from using
a key to decrypt/encrypt data), and also to support key recovery
of encrypted data under proper authority (say to comply with
a legal warrant.)

Finally, regardless of your design you must carefully weigh and
assess it's performance, doing the tradeoff between cryptography
and speed and reliability.  And you need to design it to be robust
in the face of operational failure.

Just my two cents worth (based on over a decade's worth of
cryptographic based security system design).

- Alex
--

Alex Alten
[EMAIL PROTECTED]



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


Re: Death of antivirus software imminent

2008-01-04 Thread Alex Alten

At 11:23 PM 1/3/2008 +, Steven M. Bellovin wrote:

On Thu, 03 Jan 2008 11:52:21 -0500
[EMAIL PROTECTED] wrote:

 The aspect of this that is directly relevant to this
 list is that while we have labored to make network
 comms safe in an unsafe transmission medium, the
 world has now reached the point where the odds favor
 the hypothesis that whomever you are talking to is
 themselves already 0wned, i.e., it does not matter if
 the comms are clean when the opponent already owns
 your counterparty.

Right -- remember Spaf's famous line about how using strong crypto on
the Internet is like using an armored car to carry money between
someone living in a cardboard shack and someone living on a park bench?

Crypto solves certain problems very well.  Against others, it's worse
than useless -- worse, because it blocks out friendly IDSs as well as
hostile parties.


I agree with these statements.  I have a couple of comments
regarding crypto and IDS.  I think that we will have to move toward
encrypting more data at rest in some manner that is that is easy for
the user to use (like ATM cash cards) yet difficult for a malicious
piece of software on the user's machine to circumvent.  This will
require that all PC's ship with a trusted hardware/firmware chip
AKA a reference monitor on the motherboard that can safely handle
any red keys.  This also means the PC needs a trusted path to
the user like the pin pad in ATM machines.  Many laptops now
ship with fingerprint scanners, so maybe these things are not such
an onerous requirement on PC manufacturers anymore.  Also
the reference monitor could be used to prevent viruses being able
to completely taking over the user's machine (maybe at least
to maintain some sort of host IDS capability).

For IDS, I think we need to think of it in more the context of policing.
These virus writers are human beings, and I suspect for the most
part a very small fraction of the total Internet population.  We need to
have tools and international Interpol-like treaties in place that allow
police to track down and arrest these people (or deny them access
via an ISP or a carrier).  Many of the tier 1 carriers apparently are
refusing to share IDS information with one another.  This needs to
change.  We need really good IDS tools that track down the control
lines of the botnets, etc., back to their actual handlers.  This may
mean that each carrier must archive large amounts of either netflow
data or even raw packets (say for non-TCP traffic) so that detailed
L7 analysis can take place to track botnet control lines back to their
handlers in after-the-fact investigations.  Also, I hate to say this, we
may need to also require that all encrypted traffic allow inspection of
their contents under proper authority (CALEA essentially).  If we
can do this then we can put real policing pressure on these virus
writers, essentially removing them from being able to attack us
over the Internet.

- Alex

--

Alex Alten
[EMAIL PROTECTED]



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


Re: Death of antivirus software imminent

2008-01-18 Thread Alex Alten

At 07:35 PM 1/18/2008 +1000, James A. Donald wrote:

Alex Alten wrote:
 Generally any standard encrypted protocols will
 probably eventually have to support some sort of CALEA
 capability. For example, using a Verisign ICA
 certificate to do MITM of SSL, or possibly requiring
 Ebay to provide some sort of legal access to Skype
 private keys.

And all the criminals will of course obey the law.

Why not just require them to set an evil flag on all
their packets?


These are trite responses.  Of course not.  My point is
that if the criminals are lazy enough to use a standard
security protocol then they can't expect us not to put
something in place to decrypt that traffic at will if necessary.


 If there is a 2nd layer of encryption then this would
 require initial key exchanges that may be vulnerable
 to interception or after-the-fact analysis of the
 decrypted SSL payloads.

I guarantee I can make any payload look like any other
payload.  If the only permitted communications are
prayers to Allah, I can encode key exchange in prayers
to Allah.


Yeah and you can only communicate with Allah with
that type of design.

Look, the criminals have to design their security system with
severe disadvantages; they don't own the machines they
attack/take over so they can't control its software/hardware
contents easily, they can't screw around too much with the IP
protocol headers or they lose communications with them, and
they don't have physical access to the slave/owned machines.

And, last I heard, they must obey Kerckhoff's law, despite
using prayers to Allah for key exchanges.

Given all this, I'm not saying its easy to do, but it should be
quite possible to crack open some or all of their encrypted
comms and/or trace back to the original source attack
machines.

- Alex

--

Alex Alten
[EMAIL PROTECTED]



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


malware in digital photo frames infects users computers

2008-01-27 Thread Alex Alten
Great.  What next?  I guess air-gap transfer of flash memory might be the 
best solution.


Malware's new infection route: photo frames
http://www.sfgate.com/cgi-bin/article.cgi?file=/c/a/2008/01/26/MNE7UHOOQ.DTL

- Alex
--

Alex Alten
[EMAIL PROTECTED]



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


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-03 Thread Alex Alten

At 09:34 PM 2/1/2008 +0100, Ian G wrote:

* Browser vendors don't employ security people as we know them on this 
mailgroup, they employ cryptoplumbers. Completely different layer.  These 
people are mostly good (and often very good) at fixing security bugs.  We 
thank them for that!  But they are completely at sea when it comes to 
systemic security failings or designing new systems.


An excellent observation Ian!!

I too have run into this mindset at enterprises with inhouse security teams 
(mostly in Silicon Valley).  They focus on the nuts and bolts like 
producing/using cryptographic libaries, fixing security bugs in code or 
configuring network appliances to stop intrusions.  But it is really hard 
to find any of them with decent experience or knowledge at the overall 
software/hardware/people system design level. They are often very smart and 
educated engineers. I find that there's this mindless focus on using 
groups of security standards, e.g PKI / LDAP / SSL type of combinations, 
etc.  The DoD contractor firms seem to be a little bit better at 
recognizing the system level aspects of security, although they too are 
often blinded by the emphasis on COTS security products.


- Alex
--

Alex Alten
[EMAIL PROTECTED]



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


Re: Protection for quasi-offline memory nabbing

2008-03-26 Thread Alex Alten

At 10:38 AM 3/21/2008 -0700, Jon Callas wrote:


Despite that my hypotheses are only that, and I have no experimental
data, I think that using a large block cipher mode like EME to induce
a pseudo-random, maximally-fragile bit region is an excellent
mitigation strategy.


Isn't EME patented?  - Alex

--

Alex Alten
[EMAIL PROTECTED]



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