Re: English 19-year-old jailed for refusal to disclose decryption key
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)
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)
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]
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
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
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
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.
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.
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]
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?
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?
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?
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?
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?
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
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?
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: Strength in Complexity?
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?
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?
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?
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?
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
[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
- 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
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
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
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]
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]
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
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
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
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?
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
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
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]
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
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
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
