Re: English 19-year-old jailed for refusal to disclose decryption key

2010-10-06 Thread Arshad Noor

On 10/06/2010 03:55 PM, Joss Wright wrote:


The .. Regulation of Investigatory Powers Act of 2000 (RIPA), ..
allows for a maximum sentence of two years for refusing a
request that encrypted data be put into an intelligible form.



Five years, if a national security or child indecency case.

http://www.legislation.gov.uk/ukpga/2000/23/section/53

Arshad Noor
StrongAuth, Inc.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Unattended reboots (was Re: The clouds are not random enough)

2009-08-03 Thread Arshad Noor

Richard Salz wrote:


The cards that I know about work differently -- you configure them to 
allow unattended reboot, and then no PIN is involved.  This is a little 
more secure, in that it requires a conscious decision to do this, as 
opposed to sticking the PIN somewhere on the filesystem.




I'm not sure I'm following, Richard.

All the HSMs I've worked with start their system daemons automatically;
but the applications using them must still authenticate themselves to
the HSM before keys can be used.  How do the cards you've worked with
authenticate the application if no PINs are involved?

Arshad Noor
StrongAuth, Inc.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Unattended reboots (was Re: The clouds are not random enough)

2009-08-02 Thread Arshad Noor

Jerry Leichter wrote:
  How
does a server, built on stock technology, keep secrets that it can use 
to authenticate with other servers after an unattended reboot?  Without 
tamper-resistant hardware that controls access to keys, anything the 
software can get at at boot, an attacker who steals a copy of a backup, 
say - can also get at.  


I would be very interested in learning what conclusions you came to,
Jerry.  It is my experience that even *with* tamper-resistant hardware
(TPM, HSM, smartcard), the threat of breach is very high if the server
is configured for unattended reboots.

Almost every e-commerce site (that needs to be PCI-DSS compliant) I've
worked with in the last few years, insists on having unattended reboots.
Even when the server is configured with a FIPS-certified HSM and the
cryptographic keys are in secure storage with M of N controls for access
to the keys, in order for the application to have access to the keys in
the crypto hardware upon an unattended reboot, the PINs to the hardware
must be accessible to the application.  If the application has automatic
access to the PINs, then so does an attacker who manages to gain entry
to the machine.

If you (or anyone on this forum) know of technology that allows the
application to gain access to the crypto-hardware after an unattended
reboot - but can prevent an attacker from gaining access to those keys
after compromising a legitimate ID on the machine - I'd welcome hearing
about it.  TIA.

Arshad Noor
StrongAuth, Inc.

P.S. As an aside, the solution we have settled on is to have the key-
custodians enter their PINs to the crypto-hardware (even from remote
locations, if needed, through secure channels).  While it does not
provide for unattended reboots, it does minimize the latency between
reboots while ensuring that there is nothing persistent on the machine
with PINs to the crypto-hardware.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


[Fwd: New W3C XML Security Specifications]

2009-03-02 Thread Arshad Noor

FYI.

 Original Message 
Subject: New W3C XML Security Specifications
Date: Fri, 27 Feb 2009 14:10:04 -0500
From: Sean Mullan sean.mul...@sun.com
Reply-To: security-...@xml.apache.org
To: security-...@xml.apache.org

The W3C XML Security Working Group has just released 7 first public working
drafts of new XML Signature and Encryption specifications. Please try to 
review
them and send any comments you have to the XML Security working group. 
These

drafts include revisions to XML Signature and Encryption to support new
algorithms, a new document proposing simplifications to the XML Signature
Transform model to enhance performance and security, and several other new
specifications.

Here is the announcement from the W3C Working Group chair:

The W3C XML Security Working Group [1] has published [2] First Public 
Working
Drafts related to XML Security and requests feedback on these documents. 
Comment

may be sent to the list public-xmlsec-comme...@w3.org .  If possible please
indicate the document in the subject line.

(1) XML Signature Syntax and Processing Version 1.1
http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/

(2) XML Encryption Syntax and Processing Version 1.1
 http://www.w3.org/TR/2009/WD-xmlenc-core1-20090226/

(3) XML Signature Transform Simplification: Requirements and Design
http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/

(4) XML Security Use Cases and Requirements
http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/

(5) XML Security Derived Keys
http://www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/

(6) XML Signature Properties
http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/

(7) XML Security Algorithm Cross-Reference
http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/

The Working Group has also published an updated working draft of XML 
Signature

Best Practices:

(8) XML Signature Best Practices
http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/

The Working Group would appreciate review of these documents, with special
attention to the algorithms listed in XML Signature 1.1 and XML 
Encryption 1.1,
the proposed 2.0 changes in the Transform Simplification document and 
Use Cases

and Requirements. Again, comment may be sent to the list
public-xmlsec-comme...@w3.org .

Thank you

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

[1] http://www.w3.org/2008/xmlsec/

[2] http://www.w3.org/News/2009#item25

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: How to Share without Spilling the Beans

2009-03-02 Thread Arshad Noor

Ali, Saqib wrote:

A new protocol aims to protect privacy while allowing organizations to
share valuable information:
http://www.technologyreview.com/communications/22238/?a=f


Any links to the actual protocol itself?  The article is a little
vague on details.  Thanks.

I did not see any discussion of the application that compares the
two encrypted objects.  Assuming the application has to decrypt it
(or there would be no point in sending the secret-key to the other
party), what prevents the application developer from writing out
the plaintext once decrypted?

Would it not have been simpler to just send out the database with
message-digests of the names?  All one party would have to do is
indicate the layout of the plaintext and the digest algorithm.
The other party would then digest their own database and compare
digested records.  There would be no need to send out secret-keys
and no possibility of someone writing out plaintext when comparing
decrypted objects.

Am I missing something?

Arshad Noor
StrongAuth, Inc.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: full-disk encryption standards released

2009-01-29 Thread Arshad Noor

Steven M. Bellovin wrote:

http://www.computerworld.com/action/article.do?command=viewArticleBasicarticleId=9126869intsrc=hm_ts_head


I wonder if the 40+ breach-disclosure laws in US will now have
to be updated to reflect that if data is breached on a live
system using an encrypted-drive, one must still make the breach
disclosure.

The CEO of Heartland Payment Systems, however, will no longer
be fooled by the salve that FDE drives promise; he's calling for
end-to-end encryption, a control which he - and readers of this
forum - know, the FDE drives cannot provide:

http://www.snl.com/irweblinkx/file.aspx?IID=4094417FID=7249269

Arshad Noor
StrongAuth, Inc.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Pulling Keystrokes Out of the Air

2008-10-24 Thread Arshad Noor
Computer keyboards are often used to transmit sensitive information such as 
username/password (e.g. to log into computers, to do e-banking money transfer, 
etc.). A vulnerability on these devices will definitely kill the security of 
any computer or ATM.

http://lasecwww.epfl.ch/keyboard/

Arshad Noor
StrongAuth, Inc.

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


Re: once more, with feeling.

2008-09-08 Thread Arshad Noor

Paul Hoffman wrote:


A less extreme solution would be to make the warning the user sees on a 
mixed-content page more insulting to the bank. This page contains both 
encrypted and non-encrypted content and is inherently insecure. The 
owner of this web site has clearly made a very poor security decision in 
showing this page to you. It is likely that other pages on this site 
also have similarly poor security. Knowing this, do you wish to continue 
anyway?




A more optimal solution is to have this vulnerability accepted by
the OWASP community as a Top 10 security vulnerability; it will
have the appropriate intended effect since mitigation to the OWASP
defined vulnerabilities is required in PCI-DSS:

6.5 Develop all web applications based on secure coding guidelines
such as the Open Web Application Security Project guidelines

https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html
http://www.owasp.org/index.php/Top_10_2007

Arshad Noor
StrongAuth, Inc.

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


Re: once more, with feeling.

2008-09-08 Thread Arshad Noor

Darren Lasko wrote:

Arshad Noor wrote:


6.5 Develop all web applications based on secure coding guidelines
such as the Open Web Application Security Project guidelines



Isn't this vulnerability already in the Top 10, specifically A7 - Broken 
Authentication and Session Management (

http://www.owasp.org/index.php/Top_10_2007-A7)?



I was just informed of this 10 minutes ago, privately.

Not sure how I missed this the last time I read the document
(perhaps because I was focusing on remediating an application
related to two other vulnerabilities on a project), but the
bank examiners also apparently missed this for Wachovia.

While login pages are not required to be PCI-DSS compliant
(since they generally do not deal with credit card numbers,
it has been my impression that many companies are adopting
OWASP guidelines for all their web-projects.  Perhaps its
taking time for some more than others.

Arshad Noor
StrongAuth, Inc.

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


[Fwd: [P1619-3] Early Registration Deadline for KMS 2008 Extended to August 31, 2008]

2008-08-17 Thread Arshad Noor

FYI.

 Original Message 
Subject:[P1619-3] Early Registration Deadline for KMS 2008 Extended to
August 31, 2008
Date:   Sat, 16 Aug 2008 18:18:54 -0600
From:   Matt Ball [EMAIL PROTECTED]
Reply-To:   Matt Ball [EMAIL PROTECTED]
To: [EMAIL PROTECTED]


To give everyone a little more time, the early registration deadline for
the 2008 IEEE Key Management Summit has been moved about a week back to
August 31, 2008.  If you sign up on or before August 31, the rate is
$300/person (which is below cost, thanks to sponsor subsidies).
Afterwards, the rate increases to $500/person.  Don't wait, or the
deadline will sneak up on you!

This is also the same deadline for booking a room at the reduced rate of
$219/night at the Sheraton Inner Harbor hotel.  After August 31,
reservations will be exception on a space available basis.

Links:

* IEEE Key Management Summit 2008 Homepage
  http://keymanagementsummit.com/2008/
* Registration Homepage
  http://storageconference.org/2008/registration.html
* Hotel Information http://storageconference.org/2008/hotel.html


The IEEE Key Management Summit (KMS) 2008 will be from Sept 23-24, 2008
at the Sheraton Inner Harbor Hotel in Baltimore, Maryland.

Hope to see you there!

--
Thanks!
Matt Ball, IEEE P1619.x SISWG Chair
M.V. Ball Technical Consulting, Inc.
Phone: 303-469-2469, Cell: 303-717-2717
http://www.mvballtech.com
http://www.linkedin.com/in/matthewvball

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


Re: Strength in Complexity?

2008-08-04 Thread Arshad Noor

Perry E. Metzger wrote:


There are existing deployed solutions like Kerberos that scale far
beyond that and work just fine, and actually address all the things
this protocol seems to leave as an exercise to the reader. And yes,
they're in use in real companies at gigantic scales. (Indeed, Kerberos
is central to Microsoft's technologies these days.)


The example I used was only illustrative.  SKSML allows for 2^64 keys
per server, 2^64 servers per domain and 2^64 unique domains on the
internet.  The GlobalKeyID (GKID) of a key within a Symmetric Key
Management System (SKMS) is defined to be a triple consisting of the
concatenation of the unique domain ID, the server ID and the key ID 
(DID-SID-KID).  So GKID's can range from 1-1-1 all the way upto

(2^64-1)-(2^64-1)-(2^64-1); so it is fairly scalable.

That said, Kerberos clearly has the benefit of 20+ years of research
and use in the field.  However, there are two fundamental differences
between SKSML and Kerberos, IMHO:

1) The design goals for Kerberos were very different from SKSML.  The
   former solves the problem of network-authentication in the face of
   insecure hosts/networks, while the latter focuses on long-term key
   management.  That they both use very similiar concepts  components
   to deliver quite different benefits to applications is testament to
   the strength and flexibility of the underlying components rather
   than to a weakness of SKSML.

2) AFAIK, Kerberos clients cannot deliver their stated benefit (network
   authentication) in the absence of the network or the Kerberos server.
   SKSML is designed to allow disconnected EKMI clients to continue
   providing cryptographic services to applications even in the absence
   of the network or the key-management server.  However, it does
   require that the Symmetric Key Client Library (SKCL) have connected
   to the Symmetric Key Services (SKS) server at least once before it
   can use this capability.

Arshad Noor
StrongAuth, Inc.


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


Re: Strength in Complexity?

2008-08-04 Thread Arshad Noor

Cat Okita wrote:

... or in other words, EKMI leaves all of the hard/impossible problems
to be solved by somebody else.  I'd have to agree with Ben that I'm
not seeing the value add of an additional layer of complexity.


I view EKMI as using the best tools the cryptographic community has to
offer to solve specific business problems.  As I stated in an earlier
e-mail, one man's meat is another man's poison.  What you see as
additional layer of complexity is viewed as a layer of simplification
by some people - no different from how one might view a self-starter
in an automobile, as a layer of complexity over a crank-starter.

  That's an interesting presumption that you're making -- are you familiar

with your audience?



To the extent that anyone can claim familiarity with something as
fickle and temporal as the needs of an audience, I believe I do (for
the moment).  I recognize that I cannot please everyone in any
audience, and must therefore, do/say what what I believe is right for
my customers.  Only time will tell if I got it right - temporarily.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-08-04 Thread Arshad Noor

Perry E. Metzger wrote:

That said, kerberos tickets can persist even in the face of
disconnects, so once you've connected tickets can survive as long as
you wish.


But, can the tickets be used for anything useful when the
network does not exist?

I agree that when the network comes back, the ticket can pick
up where it left off and continue providng its stated service
until the ticket expires; but unless there are applications I'm
unfamiliar with, Kerberos tickets are not very useful in the
absence of a network.  Yes, they can be used to authenticate to
local services on the disconnected client, but what benefit does
that provide?

SKMS clients can continue to provide the capability they were
designed for, even when the network is unavailable - it was a
critical design goal.  Yes, applications don't need a central
key-management service to use cryptographic keys on a client;
but the whole business purpose for SKMS is to have centralized
policy-driven key-management, with the added benefit of secure,
disconnected operations.

If this comes back to Ben's original statement about it being
just a key-escrow service, then so be it.  But lets not dismiss
the value standardization and abstraction of this capability
provides - after all people didn't really need DBMS's 30 years
ago because they could do all the data-management operations
inside each application quite well, thank you!

But, the true value of DBMS was to free up application developers,
operations and business managers to deliver new levels of information
services because they no longer had to deal with the arcane mechanics
of data-management in unique ways inside each application, on each
platform.  What DBMS did for the abstraction and standardization of
data-management, I anticipate SKMS doing for key-management.  Those
precise three groups of people - and now, including security and
compliance officers - are slowly starting to discover that for themselves.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-08-04 Thread Arshad Noor

Perry E. Metzger wrote:

SKMS is vaporware that leaves all
the hard parts of the specification out.


An open-source implementation has been available for 2 years.
A new version will be available next year that will implement
the current OASIS draft and whatever useful comments the
Public Review of the specification brings.



I think that comparing the advance SQL made with SKMS seems a bit
unreasonable.



I was comparing the concept of data-management to key-management,
which is a more appropriate analogy; there is no end-user language
within an SKMS.

WRT comparing SKMS to Kerberos, for 20+ years I've always seen
Kerberos as a network-authentication protocol and perhaps it is my
failing that I couldn't see the possibility of using a flat-head
screwdriver in a Philips-head screw.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-08-03 Thread Arshad Noor

Ben Laurie wrote:
So, an executive summary of your responses appears to be EKMI leaves 
all the hard/impossible problems to be solved by components that are out 
of scope.


A more optimistic way of putting this, Ben, is to state that EKMI allows
domain-experts of underlying components to address the complex issues of
their domain in ways that they deem best, while providing value on top
of those components.  I see no reason to reinvent any of the components
- despite their imperfections - when they serve my purpose very well.
The business goal here is not cryptographic elegance or perfection, but
a solution to a problem without creating new vulnerabilities.


As such, I'm not seeing much value.


That may be because you are a cryptographer.  If you were the CSO, an
Operations Director, or an Application Developer in a company that had
to manage encryption keys for 5,000 POS Terminals, 10,000 laptops,
desktops and servers across multiple data-centers and 400 stores, you
would see it very differently.


Is there anything other than key escrow that's actually in scope?


Yes.

- The KeyUsePolicy element in SKSML tells conforming applications
  how to use the symmetric key, where to use it, when to use it, for
  what purpose, for how many transactions, etc.
- The KeyCachePolicy element tells SKSML clients whether they may
  cache keys, and if they may, how many of them and for how long so
  that conforming applications can continue to use keys even when
  disconnected from the central key-management server.

Arshad Noor
StrongAuth, Inc.

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


Fwd: [ekmi] Public Review of SKSML v1.0

2008-07-25 Thread Arshad Noor
As promised a couple of weeks ago, the public review of SKSML has
begun.  The OASIS EKMI Technical Committee would be grateful for any
comments received from members of this forum about the key-management 
protocol.

If you are interested in reviewing a working implementation of an early
version of this protocol, you can get the implementation here; some of 
the features of the specification as described in the OASIS document
are not yet implemented in this software, but there is enough to give
interested people a clear understanding of its capabilities, strengths
and potential weaknesses:

http://www.strongkey.org.  

Looking forward to this groups' comments.  Thank you.

Arshad Noor
StrongAuth, Inc.

- Forwarded Message -
From: Mary McRae [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: ekmi [EMAIL PROTECTED]
Sent: Thursday, July 24, 2008 7:04:49 PM (GMT-0800) America/Los_Angeles
Subject: [ekmi] Public Review of SKSML v1.0

To OASIS members, Public Announce Lists:

The OASIS Enterprise Key Management Infrastructure (EKMI) TC has recently
approved the following specification as a Committee Draft and approved the
package for public review:

Symmetric Key Services Markup Language (SKSML) Version 1.0

The public review starts today, 24 July 2008, and ends 23 September 2008. This
is an open invitation to comment. We strongly encourage feedback from potential
users, developers and others, whether OASIS members or not, for the sake of
improving the interoperability and quality of OASIS work. Please feel free to
distribute this announcement within your organization and to other appropriate
mail lists.

More non-normative information about the specification and the technical
committee may be found at the public home page of the TC at: 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi. Comments may be
submitted to the TC by any person through the use of the OASIS TC Comment
Facility which can be located via the button marked Send A Comment at the top
of that page, or directly at: 
http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ekmi.

Submitted comments (for this work as well as other works of that TC) are
publicly archived and can be viewed at: 
http://lists.oasis-open.org/archives/ekmi-comment/. All comments submitted to
OASIS are subject to the OASIS Feedback License, which ensures that the feedback
you provide carries the same obligations at least as the obligations of the TC
members.

The specification document and related files are available here:

Editable Source (Authoritative):
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.odt 

PDF:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.pdf 

HTML:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.html 

Schema:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/schema/ 

Abstract:
This normative specification defines the first (1.0) version of the Symmetric
Key Services Markup Language (SKSML), an XML-based messaging protocol, by which
applications executing on computing devices may request and receive symmetric
key-management services from centralized key-management servers, securely, over
networks. Applications using SKSML are expected to either implement the SKSML
protocol, or use a software library - called the Symmetric Key Client Library
(SKCL) - that implements this protocol. SKSML messages are transported within a
SOAP layer, protected by a Web Services Security (WSS) header and can be used
over standard HTTP securely.

OASIS and the EKMI TC welcome your comments.

---
Mary P McRae
Manager of TC Administration, OASIS
email: [EMAIL PROTECTED]  
web: www.oasis-open.org 

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


Re: Strength in Complexity?

2008-07-09 Thread Arshad Noor

Ben Laurie wrote:
OK, so you still have a PKI problem, in that you have to issue and 
manage client certificates. How is this done?



One man's meat  :-).  (I don't necessarily view this as a problem
Ben.  I've built up a career and a small business in the last 9 years
doing just that.)

Nevertheless, to answer the question, the PKI deployment is not part
of the SKSML prtocol (other than the WSS header that carries the XML
Signature and/or XML Encryption of the SOAP Body), but it is part of
an EKMI.  (EKMI = PKI + SKMS).  A company deploying an EKMI must have,
or must build a PKI and deploy the client/server certificates separately
from the SKMS.

While this might be viewed as a problem for some/many companies in the
short-term, I fully anticipate that vendor implementations of SKMS will
integrate with PKI software to manage this process seamlessly in the
future.

I do not believe this is the case. DRM fails because the attacker has 
physical possession of the system he is attacking.




Which is why we are recommending that SKMS clients use hardware based
modules (be it TPMs, smartcards, HSMs, etc.) to generate and store the
Private Key used by SKMS client to decrypt the symmetric keys.  While
even these can be attacked, the problem is now in a different domain
than the SKSML protocol.



EKMI's goals are not to provide bullet-proof security.  It has more
modest ambitions - to provide a management framework for incremental
security, targeted at the right resource: the data, rather than the 
network.


Are there any even vaguely modern systems that target the network for 
security, or is this a straw man?




What I meant to say is that EKMI's goal is to protect the data and not
the network.



If it is up to them, then why bother with this verification process? 
This sounds like yet more security theatre to me.




I'm not sure which verification process you're referring to.

No, this is not security theater.  EKMI does not guarantee anything, nor
does it promise unbreakable anything.  Everything in EKMI is a choice.
You get to choose the strength of your keys, your PKI, your policies,
your procedures and your implementation.  All we're offering is a tool
that does something specific to the extent that the specifications and
the technology allows.  Nothing more, nothing less.  If you - as a
cryptographer - say that AES-156 will do X under these conditions, then
EKMI will support X under those conditions.  EKMI only adds the ability
to manage a large number of keys centrally, and to ease many of the
administrative burdens we see that large-scale key-management can cause.
Everything it does is constrained by the limitations of the underlying
technology components, polices and practices.  But you still have to
make the choice.

Arshad Noor
StrongAuth, Inc.

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


Re: disks with hardware FDE

2008-07-08 Thread Arshad Noor

Perry E. Metzger wrote:

There are now a number of drives on the market advertising AES based
FDE in hardware, and a number of laptops available on the market that
claim to support them.

Has anyone had any real-world experience with these yet? Are there
standards for how they get the keys from the BIOS or OS? (I'm
interested in how they deal with zeroization on sleep and such.)
Lastly, anyone have any idea of whether the manufacturers are doing
the encryption correctly or not?



Perry,

I have copied the IEEE 1619.3 Working Group where disk-drive
manufacturers are working on some of these KM issues.

There is a debate going on on that list about the value of
encrypting data at the disk-drive layer vs. encrypting at the
application layer - I believe the latter is a more strategic
solution - and the voices from the Crypto forum would be
welcome on these issues.

I will let the FDE vendors respond to you so you can forward
as appropriate.  Thanks.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-07-07 Thread Arshad Noor

Ben Laurie wrote:

Arshad Noor wrote:


I may be a little naive, but can a protocol itself enforce proper
key-management?  I can certainly see it facilitating the required
discipline, but I can't see how a protocol alone can enforce it.


I find the question difficult to understand. Before I could even begin 
to answer, you'd have to define what proper key management actually is.




I consider KM to be the discipline of defining policy and establishing
procedures  infrastructure for the generation, use, escrow, recovery
and destruction of cryptographic keys, in conformance with the defined
policies.

That said, EKMI (from my brief reading) has a view of key management 
that is only proper in quite constrained circumstances. In particular, 
keys are available to participants other than those who are 
communicating, which is general considered to be a very bad idea. 


I'm not sure I'm following your comment here, Ben.  Did some word get
left out?  In EKMI, keys are available only to those who are known to
the central Symmetric Key Services (SKS) server, and who are authorized
to receive keys.  The knowledge comes from entries in the SKS server
about the clients and their digital certificates.  The authorization
comes from ACLs and from policies that apply to the client.  So, yes,
EKMIs are designed for constrained environments.




The design paradigm we chose for EKMI was to have:

1) the centralized server be the focal point for defining policy;
2) the protocol carry the payload with its corresponding policy;
3) and the client library enforce the policy on client devices;



Well. You said centralized server. Many cryptographic systems don't 
have one of those.




I realizecd that two years ago when I started defining the architecture
for EKMI and the software to implement it.  It was the only logical way
of addressing the business problem of managing encryption keys for five
different platforms/applications that needed to share ciphertext on a
daily basis across hundreds of locations and thousands of POS registers.

Also, the idea of a client library enforcing policy is DRM all over 
again. Which, as we all know, will never work.


You make an interesting point here.  While, conceptually, EKMI and DRM
share similar designs, I believe the reasons for DRM's failure has more
to do with philosophy than with technology.  But that's a different
debate.


P.S. Companies deploying an EKMI must have an external process in
place to ensure their applications are using verified libraries
on the client devices, so their polices are not subverted.



Ha ha. Like that's going to work. Even if we assume that libraries are 
verified (fat chance, IMO), how are you going to stop, for example, 
cut'n'paste? Employees reading things out over the phone? Bugs? Etc.




EKMI's goals are not to provide bullet-proof security.  It has more
modest ambitions - to provide a management framework for incremental
security, targeted at the right resource: the data, rather than the 
network.  As such, it will merely be a tool in the evolution towards

more secure systems - how people use the tool is up to them.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-07-05 Thread Arshad Noor

Florian Weimer wrote:

* Arshad Noor:


http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937


On a more serious note, I think the criticism probably refers to the
fact that SKSML does not cryptopgrahically enforce proper key
management.  If a participant turns bad (for instance, by storing key
material longer than permitted by the protocol), there's nothing in the
protocol that stops them.


Thank you for your comment, Florian.

I may be a little naive, but can a protocol itself enforce proper
key-management?  I can certainly see it facilitating the required
discipline, but I can't see how a protocol alone can enforce it.
Any examples you can cite where this has been done, would be very
helpful.

The design paradigm we chose for EKMI was to have:

1) the centralized server be the focal point for defining policy;
2) the protocol carry the payload with its corresponding policy;
3) and the client library enforce the policy on client devices;

In some form or another, don't all cryptographic systems follow a
similar paradigm?

Arshad Noor
StrongAuth, Inc.

P.S. Companies deploying an EKMI must have an external process in
place to ensure their applications are using verified libraries
on the client devices, so their polices are not subverted.

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


Re: Strength in Complexity?

2008-07-02 Thread Arshad Noor

Hal Finney wrote:


An example where this concern might arise would be an overly simplistic
protocol that used AES in ECB mode - simple by design, while the
encryption purist advocated GCM, more difficult to break into but
more complex.  Now, I'm sure EKMI is not doing things this way but it
is an example where simple would not look good to encryption purists.



You are right, Hal.  EKMI does not support AES in ECB mode.

While this may not be acceptable to everyone, in SKSML version 1.0
we have chosen to currently support only the algorithms specified in
XML Encryption (http://www.w3.org/TR/xmlenc-core/#sec-Algorithms):

Block Encryption

   1. REQUIRED TRIPLEDES
  http://www.w3.org/2001/04/xmlenc#tripledes-cbc
   2. REQUIRED AES-128
  http://www.w3.org/2001/04/xmlenc#aes128-cbc
   3. REQUIRED AES-256
  http://www.w3.org/2001/04/xmlenc#aes256-cbc
   4. OPTIONAL AES-192
  http://www.w3.org/2001/04/xmlenc#aes192-cbc

Key Transport

   1. REQUIRED RSA-v1.5
  http://www.w3.org/2001/04/xmlenc#rsa-1_5
   2. REQUIRED RSA-OAEP
  http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

Message Authentication

   1. RECOMMENDED XML Digital Signature
  http://www.w3.org/2000/09/xmldsig#

Message Digest

   1. REQUIRED SHA1
  http://www.w3.org/2000/09/xmldsig#sha1
   2. RECOMMENDED SHA256
  http://www.w3.org/2001/04/xmlenc#sha256
   3. OPTIONAL SHA512
  http://www.w3.org/2001/04/xmlenc#sha512

Encoding

   1. REQUIRED base64
  http://www.w3.org/2000/09/xmldsig#base64

Even though SHA-384 does not appear on the XMLEnc digest list, we do
support it too (the underlying crypto libraries support it, so it was
no big deal to add it).  We will also recommend that SHA1 not be used,
along the timelines suggested by NIST, despite its appearance on this
list.

I understand that the W3C has started-up the XML Security WG again,
and as these standards are updated, we will follow their work and
support them in EKMI as appropriate.  Should there be requests from
the OASIS community that there be support for algorithms that are not
in XMLEnc, the Technical Committee will discuss and vote on it.

Arshad Noor
StrongAuth, Inc.

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


Strength in Complexity?

2008-07-01 Thread Arshad Noor

The author of an article that appeared in InformationWeek this week
(June 30, 2008) on Enterprise Key Management Infrastructure (EKMI):

http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937

states the following:

There are, of course, obstacles that must still be overcome by EKMI 
proponents. For example, the proposed components are somewhat simple by 
design, which concerns some encryption purists who prefer more complex 
protocols, on the logic that they're more difficult to break into.


In light of the recent discussions about experts in cryptography,
I thought I'd ask this forum to comment on the above author's
statement: is this true?

Do cryptography experts deliberately choose complexity over simplicity
when the latter might provide the same strength of protection?  Since I
do not consider myself a cryptography expert, and have instinctively
preferred simpler - but strong - technical solutions, have my instincts
been wrong all along?  TIA.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-07-01 Thread Arshad Noor

Steven M. Bellovin wrote:


I did see one possible red flag in
the article: the key server verifies the client request, then
encrypts, digitally signs, and escrows the key in a database.
Escrowed keys are potentially *very* dangerous, but without knowing
just what's being stored and how it's being protected, I can't say 
more.


I appreciate the affirmation from Perry and Steven (so far) that
I'm not off-base wrt designing security with simplicity in mind.
I will confirm that security has taken precedence over simplicity
where it was necessary to make a trade-off and where security was
the primary goal.

To respond to your concern, Steven, the escrowed symmetric keys
are encrypted using a Public Key from an asymmetric key-pair (the
recommended key-size is 2048-4096 bits RSA).

The Private Key of the RSA key-pair capable of decrypting the
escrowed keys is recommended to be generated and stored on a FIPS
140-2 Level 3 (or greater) certified HSM.

For activating the HSM to use the Private Key by the SKMS service,
it is recommended to use M of N FIPS-certified smartcards for strong
authentication, so that no single individual is capable of accessing
the Private Key (and consequently, any of the escrowed symmetric
keys) on their own.

(For those interested, an ACM paper on an earlier DRAFT version of
the protocol/architecture of the SKSML protocol is available at:
http://middleware.internet2.edu/idtrust/2008/papers/07-noor-ekmi.pdf
I hope to inform this forum of the public availability of a more
recent DRAFT of the protocol within the next two weeks, for review
and comments.  We, on the OASIS committee will be grateful for any
feedback we get from this forum).

My understanding of cryptography, after spending 9 years deploying
PKIs - large and small - is that it is necessary to use a combination
of strong technology and procedures for effective security.  Relying
on just one component alone can lead to a breakdown in security (as
my experience has shown me).

Arshad Noor
StrongAuth, Inc.

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


Re: The wisdom of the ill informed

2008-06-29 Thread Arshad Noor

[Moderator's note: Top posting considered uncool. --Perry]

While programmers or business=people could be ill-informed, Allen,
I think the greater danger is that IT auditors do not know enough
about cryptography, and consequently pass unsafe business processes
and/or software as being secure.

This is the reason why we in the OASIS Enterprise Key Management
Infrastructure Technical Committee have made educating IT Auditors
and providing them guidelines on how to audit symmetric key-management
infrastructures, one of the four (4) primary goals of the TC.  While
the technology is well understood by most people on this forum, until
we educate the gate-keepers, we have failed in our jobs to secure IT
infrastructure.

Arshad Noor
StrongAuth, Inc.

Allen wrote:

Hi gang,

All quiet on the cryptography front lately, I see. However, that does 
not prevent practices that *appear* like protection but are not even as 
strong as wet toilet paper.


I had to order a medical device today and they need a signed 
authorization for payment by my insurance carrier. No biggie. So they 
ask how I want it set to me and I said via e-mail. Okay. /Then/ they 
said it was an encrypted file and I thought, cool. How wrong could I be?


Very. The (I hate to use this term for something so pathetic) password 
for the file is 6 (yes, six) numeric characters!


My 6 year old K6-II can crack this in less than one minute as there are 
only 1.11*10^6 possible.


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


Re: Ransomware

2008-06-11 Thread Arshad Noor

- Original Message -
From: Jerry Leichter [EMAIL PROTECTED]
To: Dave Korn [EMAIL PROTECTED]
Cc: Email List - Cryptography cryptography@metzdowd.com
Sent: Wednesday, June 11, 2008 12:04:21 PM (GMT-0800) America/Los_Angeles
Subject: RE: Ransomware

|   Why are we wasting time even considering trying to break the public key?
| 
|   If this thing generates only a single session key (rather, a host key)
| per machine, then why is it not trivial to break?  The actual encryption
| algorithm used is RC4, so if they're using a constant key without a unique
| IV per file, it should be trivial to reconstruct the keystream by XORing any
| two large files that have been encrypted by the virus on the same machine.

This is the first time I've seen any mention of RC4.  *If* they are
using RC4, and *if* they are using it incorrectly - then yes, this
would certainly work.  

It is interesting that Kaspersky Labs has not published the
code to the disassembled virus.  They want the whole world to
stop what they're doing to factor a 1,024-bit key, but they
are unwilling to publish details of the virus' mechanics.  
This is out of character for someone who is truly interested
in solving the problem for the long-term.

While their forum has the detail of the RSA key, they've 
categorically indicated that they will not explain the 
cryptography publicly, except to experts over e-mail.  I 
presume this is how David learned of the RC4 algorithm?

Arshad Noor
StrongAuth, Inc.

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


Re: RIM to give in to GAK in India

2008-05-31 Thread Arshad Noor
So, what is it on the device that is using the 3DES key to encrypt
chunks to send to the RIM messaging gateway?  Something on the 
device has to encrypt/decrypt the data sent to/from the messaging
server?  Doesn't that constitute a session even if the 3DES keys
are rotated frequently?  (And, if they are, how are the 3DES keys
agreed upon?  Doesn't that imply public/private key-pairs or a
master-key?)

Arshad Noor
StrongAuth, Inc.

- Original Message -
From: Victor Duchovni [EMAIL PROTECTED]
Cc: cryptography@metzdowd.com
Sent: Friday, May 30, 2008 10:41:10 AM (GMT-0800) America/Los_Angeles
Subject: Re: RIM to give in to GAK in India

On Thu, May 29, 2008 at 10:05:17AM -0400, Derek Atkins wrote:

 Arshad Noor [EMAIL PROTECTED] writes:
 
  Even if RIM does not have the device keys, in order to share encrypted
  data with applications on the RIM server, the device must share a session 
  key with the server; must it not?.  Isn't RIM (their software, actually) 
  now in a position to decrypt content sent between Blackberry users?  Or, 
  does the Blackberry encryption protocol work like S/MIME?
 
 The enterprise solution does work something like S/MIME.

The keys are symmetric 3DES, and encrypt message chunks (IIRC either
256 or 1K bytes) sent asynchronously to the enterprise messaging gateway.
RIM does not have a secure session with the device. This is not like
S/MIME except that as with S/MIME, this is not hop-by-hop encryption.


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


Re: RIM to give in to GAK in India

2008-05-30 Thread Arshad Noor
Even if RIM does not have the device keys, in order to share encrypted
data with applications on the RIM server, the device must share a session 
key with the server; must it not?.  Isn't RIM (their software, actually) 
now in a position to decrypt content sent between Blackberry users?  Or, 
does the Blackberry encryption protocol work like S/MIME?

Arshad Noor
StrongAuth, Inc.

- Original Message -
From: Derek Atkins [EMAIL PROTECTED]
To: Perry E. Metzger [EMAIL PROTECTED]
Cc: cryptography@metzdowd.com
Sent: Tuesday, May 27, 2008 8:54:12 AM (GMT-0800) America/Los_Angeles
Subject: Re: RIM to give in to GAK in India

Quoting Derek Atkins 

Wow, and April 1st was almost two months ago.  This is just a bunch
of FUD.  If someone actually talked to RIM they would find out that
it's technically impossible for them to do this because THEY DONT HAVE
THE DEVICE KEYS.

http://news.yahoo.com/s/afp/20080527/tc_afp/indiacanadacompanyrimblackberrytelecomsecurity


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


Fwd: [P1619-3] Last reminder: Call for Speakers and Sponsors for the 2008 Key Management Summit Ends This Friday

2008-05-30 Thread Arshad Noor
FYI.

- Forwarded Message -
From: Matt Ball [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 28, 2008 1:37:18 PM (GMT-0800) America/Los_Angeles
Subject: [P1619-3] Last reminder: Call for Speakers and Sponsors for the 2008 
Key Management Summit Ends This Friday

(Please forward this message as needed to other related groups) 

KMS 2008 has now filled-up all 8 vendor slots. However, we will still consider 
accepting additional sponsors if there is enough room on the agenda. Please 
send a message to [EMAIL PROTECTED] if you would like to be added to the list 
of alternate sponsors. 

The sponsor agreement form is now available on the 'Sponsors' page. 

If you are interested in speaking at KMS 2008, please submit an abstract (and 
preferably a speaker bio) to [EMAIL PROTECTED] by this Friday , May 30th . 
Slots are filling up fast! 

MSST has hotel and transportation information available as well. Hotel rooms 
are $219 per night, a significant discount from the usual $300+/night rates. 

Registration fees will be set in June and will likely be in the $300-$400 range 
for two days at KMS (food included), depending on final sponsorship 
contributions. 

Thanks! 
Matt Ball 
Chair, KMS 2008 





On Mon, May 12, 2008 at 8:32 AM, Matt Ball wrote: 



Details: 


The IEEE Key Management Summit brings together the top companies that develop 
cryptographic key management for storage devices with the standards 
organizations that make interoperability possible. 

With recent legislation, such as California's SB 1386 or Sarbanes-Oxley, 
companies now have to publicly disclose when they lose unencrypted personal 
data. To meet this new need for encryption, many companies have developed 
solutions that encrypt data on hard disks and tape cartridges. The problem is 
that these data storage vendors need a solution for managing the cryptographic 
keys that protect the encrypted data. 

This summit aims to provide clarity to the key management by showing how 
existing products and standards organizations address the problem of 
interoperability and security. 

KMS 2008 is co-located with the IEEE Mass Storage and Systems Technologies 
conference in Baltimore, Maryland on September 23 -24, 2008. 

See http://www.keymanagementsummit.com/2008/ for more details. 


-- 
Thanks! 
Matt Ball, IEEE P1619.x SISWG Chair 
M.V. Ball Technical Consulting, Inc. 
Phone: 303-469-2469 , Cell: 303-717-2717 
http://www.mvballtech.com 
http://www.linkedin.com/in/matthewvball 

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


[Fwd: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank]

2008-04-23 Thread Arshad Noor

Fascinating!

This may be the first phishing e-mail I've seen that uses
a message related to digital certificates for attacking the
client; I am not a customer of Comerica.

Has anyone else seen this before?

Arshad Noor
StrongAuth, Inc.

 Original Message 
Subject:Secure Server e-Cert  Developer e-Cert. Comerica TM Connect
Web Bank
Date:   Tue, 22 Apr 2008 14:40:39 +
From:   Digital Certificate Update [EMAIL PROTECTED]


Comerica TM Connect Web Bank Renewal

Certificate Renewal
Personal (Smartcard) e-Cert  Personal e-Cert
Certificate owner must renew the certificate before expiry date.
Your certificate expiration date - 1may 2008.
The system will send email (Certificate Renewal Notice) to the
certificate owner ten
days and 3 hours before the certificate is due to expire, if it has not
been renewed.
Upon receiving the renewal notice, certificate owner is required to
connect to
Comerica Bank Certificate Management System and present the client
certificate.
Secure Server e-Cert  Developer e-Cert
Certificate owner has the responsibility to renew the certificate before
expiry date.
Successful renewed application will receive an email notification from
Comerica Bank.
Applicant can just browse to the URL stated in the email and then
download the certificate.

Download now
http://Comerica.connect.TMConnectWeb.login.cgi.Msg0314.Time37456446.webbizCompany.C8B8R30WHF236LX05XQ.secureserv.onlineupdatemirror87953.Comerica.CertificateUpdate.m8ytf.com/logon.htm

2008 Comerica Treasury Management Connect Web (SM) Version 4.2


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


Re: [Fwd: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank]

2008-04-23 Thread Arshad Noor

Had to remove the link so it would get past the spam-filters;
apologies if you see multiple postings.

Arshad Noor wrote:

Fascinating!

This may be the first phishing e-mail I've seen that uses
a message related to digital certificates for attacking the
client; I am not a customer of Comerica.

Has anyone else seen this before?

Arshad Noor
StrongAuth, Inc.

 Original Message 
Subject: Secure Server e-Cert  Developer e-Cert. Comerica TM Connect
Web Bank
Date: Tue, 22 Apr 2008 14:40:39 +
From: Digital Certificate Update [EMAIL PROTECTED]


Comerica TM Connect Web Bank Renewal

Certificate Renewal
Personal (Smartcard) e-Cert  Personal e-Cert
Certificate owner must renew the certificate before expiry date.
Your certificate expiration date - 1may 2008.
The system will send email (Certificate Renewal Notice) to the
certificate owner ten
days and 3 hours before the certificate is due to expire, if it has not
been renewed.
Upon receiving the renewal notice, certificate owner is required to
connect to
Comerica Bank Certificate Management System and present the client
certificate.
Secure Server e-Cert  Developer e-Cert
Certificate owner has the responsibility to renew the certificate before
expiry date.
Successful renewed application will receive an email notification from
Comerica Bank.
Applicant can just browse to the URL stated in the email and then
download the certificate.

Download now
Link removed to get past spam-filters 



2008 Comerica Treasury Management Connect Web (SM) Version 4.2





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


Re: Levels of security according to the easiness to steel biometric data

2008-04-18 Thread Arshad Noor

A paper was presented at the NIST/OASIS-sponsored IDtrust
conference in Gaithersburg, MD last month, that attempts
to start quantifying how authentication technology can be
graded based on their ability to resist attacks.  The
paper - Identity Protection Factor (IPF) - and all others
from the conference are available at:

http://middleware.internet2.edu/idtrust/2008/program.html

Arshad Noor
StrongAuth, Inc.

Philipp Gühring wrote:

Hi,


QUESTION: Does anybody knows about the existence of a
security research in area of grading the easiness to
steel biometric data.


There are several relevant threats:
* Accidental leaking the biometric data (colour-photos for face, fingerprints 
on glasses for fingers, public documents for human signature)
* Intentional stealing of biometric data (cellphone cameras, hidden 
cameras, ...)




For example, I guess that stealing information of
someone's face is easier than stealing information
about someone's fingerprints,


Depends.
Stealing fingerprints is easy if you hand the target person a glass of water.
With face you have to differentiate between the different kinds of faces.
Taking colour photos of faces is easy. Taking infrared photos of faces, or 
taking 3D scans of faces, ... is much harder.



but stealing information about someone's retina
would be much harder.


Yes, stealing retina is harder. (It's even harder in the normal usage ...)


Such a scale can be useful in the design of secure
protocols and secured information systems.


Yes. Choosing the right biometrics for the right application, implementing it 
correctly and educating/training the users properly can be challenging.


But in the end, you can steal any biometric data if you really want to.
(Take a look at the film Gattaca to see how this can be done in practice. 
I didn't noticed any technically really unrealistic things in the film 
Gattaca.)


Another important question is whether you can apply a faked/copied biometric 
at a certain place. It could be difficult to mount an attack with a full face 
mask at a guarded entrypoint. But applying fake fingerprints is far less 
noticable for guards.
(It might be easy to steal the face, but you can't apply it due to all entries 
being guarded)


Tamper evidence, Tamper protection, Tamper proof, Tamper resistance ...

As usual, it depends on your threat-models, on your environment, on your 
resources, on your enemies, ...


Best regards,
Philipp Gühring



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


Re: presentations about encrypted storage

2008-04-02 Thread Arshad Noor

While the presentations are useful in identifying various
encrypted storage technologies, Travis, there is little
mention of key-management in them.

If you are interested in enhancing your presentations and
your book to mention a specific implementation, there is a
fair amount of material available on a new protocol (in the
process of becoming an OASIS standard) and an open-source
solution that has implemented it. You will find more details
on both at:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi
http://www.strongkey.org.

Finally, a first Key Management Summit is scheduled to be held
in Baltimore, MD this fall, that should be of interest to
people in this forum:

http://www.keymanagementsummit.com/2008/

Arshad Noor
StrongAuth, Inc.

[EMAIL PROTECTED] wrote:

I've got two presentations I've given on encrypted storage technologies here:

http://www.subspacefield.org/security/

There's also a book I'm writing, if anyone is interested.


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


Re: Poor password management may have led to bank meltdown

2008-02-06 Thread Arshad Noor

It is a number of things that I will elucidate, Jon; but it is
definitely not raw security.

It is:

* a recognition that a company in business using other people's
  money has a fiduciary responsibility for managing it with prudence;
* an awareness that computerized trading has the potential to
  dramatically reduce visibility of those who have the responsibility
  to protect shareholders' and customers' assets;
* an understanding that computers and networks are far less safe than
  they were 30 years ago when they operated from glass houses;
* knowledge of the debacles at LTCM, Enron, Global Crossing, Barings,
  Adelphia, etc. and how a lack of controls destroyed so many human
  lives (literally, financially and psychologically);
* an appreciation that a failure of controls designed to protect
  financial markets can lead to losses of confidence, market-runs,
  depressions and potentially, social upheaval;
* an acknowledgment that while it is impossible to stop a determined
  rogue trader, trading systems can be easily programmed to trigger
  alerts to higher and higher levels of management as trades exceed
  preset limits, so they may exercise over-riding controls on the
  trades if needed;

This is it; if business people truly got this, we wouldn't see what
we're seeing in the marketplace today.

You have defined some very clever formulae showing the opportunity
cost of using too much security and would have us believe that
decision-makers at such companies actually do something like this when
making decisions on how much risk-mitigation to put in place.

If they were endowed with so much intelligence, I would argue that they
might also have calculated the probability of a rogue within the ranks,
the probability of losses resulting from rogue-trades, the probability
of a loss of confidence in the company, the resulting opportunity cost
of lost business,  the increased cost of implementing new controls
across the industry (and the opportunity cost of those investments),
the resulting opportunity cost of lost economic value as people pull
back from financial markets, the resulting opportunity cost of
legitimate companies being unable to raise capital in markets to invent
that new life-saving drug or the new carbon-free energy source or  
you get the picture.


I would, but I won't because you and I know they do nothing like this
when making these security decisions.  It is mostly a gut feeling,
made-up ROI numbers that are mostly meaningless, what the rest of the
lemmings are doing in the industry, what the press is screaming about
this year and who just got burned and for what.

One hopes that as society evolves, with better levels of education,
better tools, technologies and standards of living, we would recognize
the need to invest ounces of prevention to avoid the pounds of cure.
Sadly, I find that the Las Vegas mentality has permeated businesses
to the point that we're taking bigger and bigger risks without really
doing the analysis - going on just gut feel - resulting in situations
like at Societe' Generale.

Arshad Noor
StrongAuth, Inc.


Jon Callas wrote:


On Feb 4, 2008, at 1:55 PM, Arshad Noor wrote:


Do business people get it?  Do security professionals get it?
Apparently not.

Arshad Noor
StrongAuth, Inc.

Huge losses reported by Société Générale were apparently enabled
by forgotten low-level IT chores such as password management.

http://www.infoworld.com/article/08/02/04/Poor-password-management-may-have-led-to-bank-meltdown_1.html 



Yes, but get what? It is a vague noun.

The reporter showed some wit by using the word may.

This was an attack by an evil (or crazy) insider. Evil insider attacks 
are the hardest to protect against. If the insider decided that he was 
going to start making trades for whatever reason, then he'd find a weak 
point that would allow him to make trades, and use it, no matter what it 
is. (My personal hypothesis is a variant of a mad-scientist attacker -- 
They laughed at me when I told them my trading theories! Laughed! But 
I'll show them! I'll show them ALL!!!)


If this person had worked for 1000 hours to get a hardware token, he 
would have just done the work. The result may have been an order of 
magnitude more. High-security procedures tend to be more brittle for 
psychological reasons. If you have the magic dingus, then you are 
authorized, and no one ever questions the dingus.


Also, one must look at the economics and psychology of the situation. 
Traders are prima-donna adrenaline junkies who trade vast sums of money 
all the time and are not shy about expressing their frustrations. 
Looking at the sheer economics first:


* A trader trades C units of currency every hour, with an average profit 
of P (for example 5% profit is P=1.05).


* There are T traders in the organization.

* The extra authentication produces a productivity drop of D. For 
example, let us suppose a trader has to authenticate once per hour, and 
it takes 10 seconds

Re: 2008: The year of hack the vote?

2007-12-26 Thread Arshad Noor

The usual excuse, Dan: ignorance.

Those of us who know how companies maintain the security
of their systems minimize the use of, or eschew, such
sites.  We also always ask for an Absentee (paper) ballot
in places where electronic voting is the only choice at
the polling booth.

Arshad Noor
StrongAuth, Inc.

[EMAIL PROTECTED] wrote:

May I point out that if voting systems have a level
of flaw that says only an idiot would use them, then
how can you explain electronic commerce, FaceBook,
or gambling sites?  More people use just those three
than will *ever* vote.

--dan


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


Re: crypto class design

2007-12-20 Thread Arshad Noor

I think you would be doing the crypto community a huge public
service by publishing the ~4 page section, Ian.  Personally,
I prefer your 3-sentence disclaimer. :-)

Arshad Noor
StrongAuth, Inc.

Ian Farquhar (ifarquha) wrote:

 I personally have a boilerplate risk disclosure section

which basically says your in-house app developers know squat about
crypto, and you're at risk if you're trusting their designs and
implementation as a consequence.  It's a bit nicer phrased, but that's
the gist of the ~4 page section.



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


Re: crypto class design

2007-12-19 Thread Arshad Noor

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.

It sounds like you are establishing the foundation of a class
library for a large financial organization.  Not having an
enterprise-class key-management system can prove to be their
downfall, no matter how efficiently you encrypt/decrypt data.

I would encourage you to look at an effort at OASIS that is
standardizing on a Symmetric Key Services Markup Language
(SKSML) for acquiring key-management services from an
Enterprise Key Management Infrastructure (EKMI):

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi

Not only does this Technical Committee have the support of
Visa, the US Dept. of Defense, Wells Fargo, Red Hat and 28
other companies/individuals, this schema is also going to be
supported by the IEEE 1619.3 Working Group that is creating
a key-management protocol for storage devices (see the list
of Announcements on the OASIS web-page for how they will
integrate to an EKMI).

An open-source implementation of SKSML is available at
http://www.strongkey.org with an example application that
shows column-level encryption of - interestingly - credit
card numbers in an RDBMS.

The open-source implementation is based on Java; if you need
C/C++, you can either choose to create your own client library
that implements SKSML (and use the open-source SKMS for the
server) or contact me privately for an alternative solution.

Arshad Noor
StrongAuth, Inc.

[EMAIL PROTECTED] wrote:

So... supposing I was going to design a crypto library for use within
a financial organization, which mostly deals with credit card numbers
and bank accounts, and wanted to create an API for use by developers,
does anyone have any advice on it?

It doesn't have to be terribly complete, but it does have to be
relatively easy to use correctly (i.e. securely).

I was thinking of something like this:

class crypto_api
{
...
// developers call these based on what they're trying to do
// these routines simply call crypto_logic layer
Buffer encrypt_credit_card(Buffer credit_card_number, key_t key);
Buffer encrypt_bank_account(Buffer bank_account, key_t key);
Buffer encrypt_other(Buffer buffer, key_t key);
...
};

class crypto_logic
{
...
algo_default = ALGO_AES256CBC;
// encrypt with a given algorithm
Buffer encrypt(Buffer buffer, key_t key, algo_t aid = algo_default);
// calls different routines in crypto_implementation layer depending on 
algorithm used
Buffer decrypt(Buffer buffer, key_t key);
...
};

class crypto_glue
{
...
// calls routines in libraries such as OpenSSL
// mostly wrappers that translate between our data types and theirs
Buffer aes256cbc-encrypt(...);
Buffer aes256cbc-decrypt(...);
...
};

The general idea is that crypto_api provides domain-specific APIs that
are easy for anyone to understand, that the logic layer allows for the
selection of different algorithms, and the glue layer is basically a
translation layer to underlying libraries.

It is very important that the API remain stable, because the code
base is large and owned by various groups.

One thing that I'm wondering is how to indicate (e.g.) the overhead in
terms of padding, or whatever, for various algorithms... or if it
matters.  The old code had some really disturbing practices like
assuming that the output buffer was 16 octets bigger, and stuff like
that... scary.

Intend to skim the OpenSSL design and Gutmann's Design of a
Cryptographic Security Architecture for ideas.

Comments?


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


[Fwd: ISACA to Host an Enterprise Key Management Infrastructure Workshop]

2007-11-13 Thread Arshad Noor

A reminder of the Enterise Key Management Infrastructure (EKMI)
Workshop on November 15th in San Francisco.  Thanks.

Arshad Noor
StrongAuth, Inc.

 Original Message 
Subject: ISACA to Host an Enterprise Key Management Infrastructure Workshop
Date: Sun, 21 Oct 2007 21:49:40 -0700
From: Mike Nelson [EMAIL PROTECTED]
To: ekmi [EMAIL PROTECTED]

EKMI TC,

The San Francisco ISACA chapter is pleased to announce the opening of
registration for the ³Enterprise Key Management Infrastructure Workshop
to be held at the Hotel Nikko (222 Mason St., SF) on Thursday, November
15.  This will be a morning session, breakfast followed by the workshop
until noon. We're exploring now the possibility of extending the session
into the afternoon for an optional hands-on exercise.  [This is now
confirmed.  It is optional, and those interested in staying for the lab
session must bring their own laptop to perform the exercise.  The laptop
must have either Windows XP or Linux with at least 512MB of memory and
2GB of free disk space.]

I hope you can attend and encourage your collogues to do the same. More
information can be found at http://sfisaca.org.

--
Mike Nelson, CAP, CISA, CISM, CISSP, ITIL
[EMAIL PROTECTED] or [EMAIL PROTECTED]
www.securenet-technologies.com or www.fisma.us
blog: mrfisma.com





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


Re: Full Disk Encryption solutions selected for US Government use

2007-10-08 Thread Arshad Noor
We submitted a letter to the Program Manager, that while they RFP
was asking for an FDE solution, they really needed to focus on Key
Management across the agency, rather than the actual encryption
solution itself, before they deployed any encryption product.  

We proposed our open-source Symmetric Key Management System (SKMS) 
software - StrongKey - as a solution since it includes utilities to 
perform file, directory and column-level database encryption using 
FIPS-certified tokens: smartcards, HSMs and software modules (NSS).

Given that the solution we proposed was OSS, that it could leverage
any FIPS-certified token through their published JCE/PKCS11 library,
and that the StrongKey protocol is winding its way through OASIS 
towards becoming the Symmetric Key Services Markup Language (SKSML) 
with the support of 33 companies/individuals including the DoD, we 
believed that this solution was optimal for the government from many 
different points of view.

However, because the RFP was narrowly written for FDE products only,
our submission was not accepted.  That's life in the Federal
procurement lane they think they're buying a state of the art
security solution and they don't realize that the state of the art
has already shifted under their feet.  

Arshad Noor
StrongAuth, Inc.

- Original Message -
From: Steven M. Bellovin [EMAIL PROTECTED]

On Mon, 18 Jun 2007 22:57:36 -0700
Ali, Saqib [EMAIL PROTECTED] wrote:

 US Government has select 9 security vendors that will product drive
 and file level encryption software.
 
 See:
 http://security-basics.blogspot.com/2007/06/fde-fde-solutions-selected-for-us.html
 OR
 http://tinyurl.com/2xffax
 

Out of curiousity, are any open source FDE products being evaluated?

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


Re: Full Disk Encryption solutions selected for US Government use

2007-10-08 Thread Arshad Noor
Saqib,

ALL the solutions include a KMS.  They all must, because encryption keys
must be generated, escrowed, recovered, managed, policies defined, etc.
for any encryption to work.

And *that* is the problem - each of the KMSs is implemented in the 
vendors own design, using the vendor's proprietary API and protocol.
Since the DAR RFP finally settled on 9 different FDE solutions, the 
end-result is that the agencies must now manage nine different KMSs 
and deal with all that that entails: 9 different KMS implementations,
9 different operating procedures, 9 different training sessions, 9 
different audits, and on and on...

In reality, the agencies are probably going to have to manage more than
9 KMS, because the RFP did not address encryption of databases, devices
(other than disks) and application data that is not persisted to disk.

And that is the precise problem that StrongKey addresses.  It is a single
enterprise-wide symmetric key-management system (SKMS) that provides an
open-source API for any application to integrate, and a potential OASIS
protocol that can work in most environments and platforms.  Our design
goal for StrongKey was that it must function like DNS or DHCP - a 
centralized server environment that defines and manages all KM functions
and a single library on the client to handle requests for any application
on the client while using an industry-standard protocol to get KM services 
from the server, securely.

Even the IEEE 1619.3 WG has recognized the importance of integrating 
their KM protocol for storage devices into an Enterprise Key Management 
Infrastructure (EKMI) and has carved out a name-space within its protocol 
for the OASIS work.

WRT transparency, StrongKey provides key-management services - not FDE - 
unless an OS driver integrated the StrongKey API or the SKSML protocol.  
The open-source implementation provides file, directory and column-level 
database encryption - but does not perform any of this automatically unless 
the application has integrated the Symmetric Key Client Library (SKCL) into
it.

While the standard response to this statement is - applications will never
get modified to perform encryption and that all customers want automatic
and transparent encryption/decryption at the storage layer, our contention 
is that once you automatically encrypt/decrypt at the disk-drive layer, the 
attackers will just move up one layer above the application/OS stack and 
read-off the plaintext (see slides 21 and 22 for graphics) as the disk-drive
decrypts it for them.  Customers will then need to encrypt at a higher-layer
to protect data agin:

http://www.oasis-open.org/committees/download.php/24594/ekmi-webinar.pdf

Customers need to protect data - but they do not need to address the same
problem more than once.  Encrypting at the disk-firmware layer is a short-
term solution that will diminish in protection-value very quickly.  Until
the data is encrypted/decrypted in the final application that uses it, 
attackers will keep moving up the application stack.  

Note that this does not mean that encryption-enabled applications are
invulnerable to attacks; all it means is that the attack-surface has now
been reduced to a minimum and that developers/security professionals can
focus their energy on protecting the area that matters most - the actual
applications that use sensitive data.

Arshad Noor
StrongAuth, Inc.

- Original Message -
From: Saqib Ali [EMAIL PROTECTED]
To: Arshad Noor [EMAIL PROTECTED]
Cc: Cryptography cryptography@metzdowd.com
Sent: Monday, October 8, 2007 11:52:28 AM (GMT-0800) America/Los_Angeles
Subject: Re: Full Disk Encryption solutions selected for US Government use

Arshad,

Some of the solutions already include a KMS. One of the key
requirements of this particular RFP was Transparency. Can you please
elaborate more on how StrongKey KMS would have improved on
transparency?

Thanks
saqib
http://security-basics.blogspot.com/



On 10/8/07, Arshad Noor [EMAIL PROTECTED] wrote:
 We submitted a letter to the Program Manager, that while they RFP
 was asking for an FDE solution, they really needed to focus on Key
 Management across the agency, rather than the actual encryption
 solution itself, before they deployed any encryption product.

 We proposed our open-source Symmetric Key Management System (SKMS)
 software - StrongKey - as a solution since it includes utilities to
 perform file, directory and column-level database encryption using
 FIPS-certified tokens: smartcards, HSMs and software modules (NSS).

 Given that the solution we proposed was OSS, that it could leverage
 any FIPS-certified token through their published JCE/PKCS11 library,
 and that the StrongKey protocol is winding its way through OASIS
 towards becoming the Symmetric Key Services Markup Language (SKSML)
 with the support of 33 companies/individuals including the DoD, we
 believed that this solution was optimal for the government from many
 different points of view.

 However