Security/Crypto/E-commerce Tutorial site - improvements
I recently put the foils of a course `Intro to Cryptography with applications to e-commerce` in http://www.hrl.il.ibm.com/mpay/course/course.html. You `buy` the lectures using our IBM Micro Payments demo. Some of you had problems downloading the foils, usually using non-windows machines. We've added `wallet server` support so now your don't have to install our wallet (you can still install it to get one-click access, if you use windows). Also, I've added two more lectures: -- A set of foils on `Payments for Internet and Mobile Commerce (Overview)` -- A paper on `Overview of Security and Payments for Mobile Commerce` Feedback welcome (on the lectures and overview as well as on our projects). Please forward this informations to others who may be intersted. Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com
WAP security - anything except WTLS?
In the WAP documentation I've found, only the WTLS mechanism is described. However I encountered some mention of additional security (cryptographic) mechanisms in WAP, maybe for form signing (application layer) - can anyone shade some light or point me to the right forum/group/site/paper? Many thanks... (why I need it ? finishing an overview on security for mobile commerce... other inputs welcome... ) Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com From [EMAIL PROTECTED] Mon Sep 11 11:17:52 2000 Envelope-to: archive@jab.org Received: from csf.colorado.edu ([128.138.129.195]) by zamboni.jab.org with esmtp (Exim 3.12 #1 (Debian)) id 13YY9Q-000778-00 for ; Mon, 11 Sep 2000 11:17:52 -0700 Received: from localhost ([127.0.0.1] helo=csf.colorado.edu) by csf.colorado.edu with esmtp (Exim 3.14 #2) id 13YYEz-0001nx-00; Mon, 11 Sep 2000 12:23:37 -0600 Received: from galaxy.csuchico.edu (galaxy.CSUChico.EDU [132.241.82.21]) by csf.colorado.edu (8.9.3/8.9.3/ITS-5.0/csf) with ESMTP id MAA06930 for <[EMAIL PROTECTED]>; Mon, 11 Sep 2000 12:23:32 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by galaxy.csuchico.edu (8.8.8/8.8.8) with SMTP id LAA23315; Mon, 11 Sep 2000 11:16:17 -0700 (PDT) Received: from popmail.lmu.edu (host-157-242-50-240.dhcp.lmu.edu [157.242.50.240]) by galaxy.csuchico.edu (8.8.8/8.8.8) with ESMTP id LAA23210 for <[EMAIL PROTECTED]>; Mon, 11 Sep 2000 11:11:18 -0700 (PDT) Received: from [157.242.206.54] by popmail.lmu.edu (NTMail 4.30.0013/NT2109.01.19acd5a3) with ESMTP id mplsgaaa for <[EMAIL PROTECTED]>; Mon, 11 Sep 2000 11:08:41 -0700 Message-Id: <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 11 Sep 2000 11:05:35 -0700 To: [EMAIL PROTECTED] From: Jim Devine <[EMAIL PROTECTED]> Subject: Re: Re: Re: Re: Economics and Literature In-Reply-To: References: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galaxy.csuchico.edu id LAA23211 Reply-To: [EMAIL PROTECTED] X-Listprocessor-Version: 8.2.08 -- ListProc(tm) by CREN X-Mailing-List: [EMAIL PROTECTED] Precedence: bulk Sender: [EMAIL PROTECTED] Doug wrote: >>I'm amazed that the literary qualities of even chap. 1 of Capital are >>being called into question. Section 4 is one of Marx's most deservedly >>famous passages, the analysis of commodity fetishism, which blends >>political economy, pyschology, philosophy, and cultural analysis in >>dazzling ways. As much as I admire Keynes as a stylist, nothing he wrote >>holds a candle to this. Brad ripostes: >... ยง4 may be dazzling to you literati but 'tain't hardly accessible to >the toiling masses... It's true that Marx (vainly) hoped that workers would be able to read his CAPITAL. But it's important to remember that the German working-class of his day had a relatively high level of literacy, partly or even largely due to their own efforts at self-education. In any event, as many have shown, it's possible to translate Marx's book into a readable form (while updating it). I haven't gotten my copy yet, but Charlie's book promises to fit this bill. I notice that economics articles and books aren't even meant to be read except by the Profession. I guess that fits with the fact that most of it is totally wrong-headed (so that if a worker were to understand it, he or she would say "nonsense!") or is esoteric (so that it's irrelevant to life on earth), or is helping the economic power elites organize peoples' lives (so that workers who understood it might have a better understanding of how they're being screwed). Jim Devine [EMAIL PROTECTED] & http://bellarmine.lmu.edu/~jdevine
Re: Secrets & Lies, a comment (proactive security)
Ed replied to me, > [EMAIL PROTECTED] wrote: > > > Ed says, > > > > > The solution is to use a multifold of links, arranged in time and space > > > such that rather than making the impossible assumption that "no part > > > will fail at any time," we can design a system where up to M parts can > > > fail at any time provided that not all M parts fail at the same time -- > > > where M can be the entire number of parts. > > > > This sounds like `proactive security`, as defined in several cryptographic > > works. You may want to check it out at http://www.hrl.il.ibm.com/proactive > > But you make the assumption that "as long as most systems are secure most of the time." > which I do not find necessary. Different works (algorithms, protocols) are able to achieve different thresholds in the number of corrupt systems tolerated. Of course ideally we would like solutions where the system is secure provided that one part is secure - but this may be hard or even impossible to achieve for some tasks. BTW, we do have one result which works in this extreme case (one part secure is enough) but with an additional assumption (I'm refering to the randomization works I've done with Ran Canetti and Chee-seng Chow around 1994-1995, see in the site). But for many harder tasks like signatures, secret sharing, clock sync... a majority (or even more) is provably necessary. BTW, often just increasing the threshold of faults from say a quarter to a third or to half, is often a very challenging task. Best, Amir
Re: Secrets & Lies, a comment
Ed says, > The solution is to use a multifold of links, arranged in time and space > such that rather than making the impossible assumption that "no part > will fail at any time," we can design a system where up to M parts can > fail at any time provided that not all M parts fail at the same time -- > where M can be the entire number of parts. This sounds like `proactive security`, as defined in several cryptographic works. You may want to check it out at http://www.hrl.il.ibm.com/proactive Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com
Course foils available: Introduction to Cryptography and Electronic Commerce
I've put the entire set of .pdf foils I've made for the course `Introduction to Cryptography and Electronic Commerce` available from http://www.hrl.il.ibm.com/mpay/course.html. The material is presented `as-is` on a best effort basis, and may contain inaccuracies and errors (reports welcome); I make no warranties of precision and accuracy. I also list references to additional courses or tutorials in these areas (I'll be happy to add / host more here). I gave this course in the Inter-Disciplinary Center in Hertzelia, Israel, at 1999. Reuse is encouraged, please retain reference to this page and to the original title and author(s). Notice: downloading is free, but... most documents require `paying` using IBM Micro Payments demo money (which you'll get in the site). Our design is for this to be `non-obstrusive` for users who do not have the wallet installed, so even in this case you should see the page well and follow all links. Warning: a (natural?) bias to `my` topics exists in this course; I will attempt to improve this in the future (using your contributions?). Comments, suggestions and corrections (on both the course and on the IBM Micro Payments demo) will be appreciated. Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com
Re: RFC 2828 on Internet Security Glossary (fwd)
supposed to compromise the "previous" one, which is "backward" > rather than forward. In S/KEY, if the key used at time t is > compromised, then all keys used prior to that are compromised. If > the "long-term" key (i.e., the base of the hashing scheme) is > compromised, then all keys past and future are compromised; thus, > you could say that S/KEY has neither forward nor backward secrecy. Great confusion here. I hope the defs above will help clear this up. I'm still unsure what the authors meant by `backwards`... > (C) Asymmetric cryptography vs. symmetric: Experts disagree about > forward secrecy in the context of symmetric cryptographic systems. > In the absence of asymmetric cryptography, compromise of any long- > term key seems to compromise any session key derived from the > long-term key. For example, Kerberos isn't forward secret, because Computational forward secrecy (i.e. not perfect) can be achieved by simply changing keys periodically as a one way function of previous keys, so that their exposure does not give past keys. This has some synchronization problems, of course. But of course Kerberos does not do this. > (C) Ordinary forward secrecy vs. "perfect" forward secret: Experts > disagree about the difference between these two. Some say there is > no difference, and some say that the initial naming was > unfortunate and suggest dropping the word "perfect". Some suggest > using "forward secrecy" for the case where one long-term private > key is compromised, and adding "perfect" for when both private > keys (or, when the protocol is multi-party, all private keys) are > compromised. I believe the term `perfect` is from the crypto theory terminology, where `perfect` is usually associated with information theory security against an a computationally unbounded adversary. Unfortunately I don't think that real PFS is possible, definitely the protocols (e.g. Diffie-Hellman based) proposed do not achieve it, since a computationally unbounded attacker can break the DH exchange (by doing discrete logs). So PFS is really a poor name, IMHO. Better drop the `perfect` term which is misleading. OTOH, it sounds nice :-) Best Regards, Amir Herzberg Special disclaimer: the defs above are not to be taken seriously as were written in few minutes, I'm afraid. IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com "P.J. Ponder" <[EMAIL PROTECTED]> on 05/30/2000 11:27:19 PM Please respond to "P.J. Ponder" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc:(bcc: Amir Herzberg/Haifa/IBM) Subject: RFC 2828 on Internet Security Glossary (fwd) There is a new Internet Draft entitled 'Internet Security Glossary' which defines terms and provides references. One purpose of the new glossary is to harmonize usage within Internet standards documents. See end of message for the URL. related to the recent discussion on defining 'forward secrecy', this new glossary has the term 'perfect forward secrecy', but that entry only directs one to: 'public-key forward secrecy', which has the following definition (and call for assistance). (The paragraphs denoted 'I' are Internet related; the ones marked 'C' are comments from the editors.) $ public-key forward secrecy (PFS) (I) For a key agreement protocol based on asymmetric cryptography, the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised if one of the private keys is compromised in the future. (C) Some existing RFCs use the term "perfect forward secrecy" but either do not define it or do not define it precisely. While preparing this Glossary, we tried to find a good definition for that term, but found this to be a muddled area. Experts did not agree. For all practical purposes, the literature defines "perfect forward secrecy" by stating the Diffie-Hellman algorithm. The term "public-key forward secrecy" (suggested by Hilarie Orman) and the "I" definition stated for it here were crafted to be compatible with current Internet documents, yet be narrow and leave room for improved terminology. (C) Challenge to the Internet security community: We need a taxonomy--a family of mutually exclusive and collectively exhaustive terms and definitions to cover the basic properties discussed here--for the full range of cryptographic algorithms and protocols used in Internet Standards: (C) Involvement of session keys vs. long-term keys: Experts disagree about the basic ideas involved. - One conc
Re: Electronic elections.
David has responded to Dan as follows (note much skiped): > >There is no doubt whatsoever that the sanctity of a vote once > >cast can be absolutely preserved as it is moved from your house > >to the counting house. What cannot be done, now or ever, is to > >ensure the sanctity of the voting booth anywhere but in a > >physical and, yes, public location attended to by persons both > So I typically elect to vote by mail. Is my vote worthless because of that? I know that the US allows voting by mail. Many other countries do not. The reason for not allowing it in many countries, or restricting it to special circumstances where physical voting is impossible, is due to the security concern Dan raised. It is of course possible to decide that the advantages of allowing voting from home, for a particular purpose, outweight the security concerns. This is a legitimate tradeoff and the right choice depends on the particulars of each election. The reason I'm writing all this is because I resented David's end note: > So standing in line with the masses like some Russian waiting for > bread somehow immunizes against voter fraud? > Yeah right... real purty flame there, real Daughters of the American > Revolution material, blood of the liberators and all, but how about a real > argument? Or is your retro dogma supposed to be lapped up > on the basis of your empty, inflamatory assertions As I explained, I believe that there are serious advantages and risks to both approaches, and in any case a civilized discussion is more fruitful (and fun) than name-calling and offensive methaphors. Furthermore I think Dan clearly made a real argument, to which David's only answer was `well if it's a problem how come a comparably insecure sceanrio is acceptable in my case` - and even that argument could have been made more clearly. There are better counter arguments, such as that physical attendance is a substantial barrier for some voters so by requiring it we deny them their right and may tilt the results. I'll conclude by noting two important differences between mail voting and Internet voting; I hope David will allow them as `real arguments`... 1. Mail voting is a non-trivial process, and in many cases less convinient than Internet voting; as a result it is also acceptable in many cases to restrict it to special circumstances. Internet voting may be much more convinient and hence popular, therefore concerns about its security may be more critical. 2. Physical mail is very low-tech. This means that it is available to (well, almost) every elligible voter. Presently, convinient Internet access is not yet available to weak populations. Therefore by making Internet voting so much easier, weak populations may be (even less) represented than today. 3. Existing operating systems used by Internet machines are far from being secure. Therefore if Internet voting will allow voting using any browser and OS, then a virus could easily vote for many users... To be fair, concerns 2 and 3 above may be addressed if the government will create a `secure voting` device and distribute one for each voter, the device requiring you just to connect it to the phone (or maybe not even this?). It is doable, in theory. And maybe it will be done once. Maybe. And maybe these devices will even be trustworthy. Maybe. Until then, I prefer traditional voting for critical decisions. Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com
XML schema to define certificate and extension profiles for interoperability
A basic problem in using certificates (and attribute certificates) from multiple issuers (CAs) is that each may issuer has a different set of extensions (where an extension may be a composite set of attributes). With X.509, there may be an ASN specification of the extension, but I'm not aware of a standard way of obtaining it or interpreting it - is there? I think an important use of XML would be for defining such extensions and attributes in a well-defined way which will allow interoperability amoung multiple certificate issuers and applications using the certificates. For example, our Trust Establishment system provides a pretty easy system for allowing applications to use (x.509 or other) certificates from diverse issuers, some of which may not be known in advance, but presently we assume each certificate has an XML certificate profile associated with it (using a simple schema/DTD we defined). Clearly, to really allow such interoperability in practice, it is desirable that such a certificate/extension/attributes definition would be standardized. BTW, I'm not too happy with our current profiles and therefore, while I'll be happy to post them if people are interested (you can also get them as part of the package if you download), I actually think we need something different. In particular I believe we could have a spec which can reuse the ASN definitions, as well as much of the ASN logic. In particular I've been recently looking into ways to define profile which are compatible with ASN, a particular one seems to be XER, or XML Encoding Rules (for ASN). I wonder if others have been looking into XER or have other ideas on what would be the right way or what are the requirements, to describe such certificate/extension/attributes format. Another BTW, I think this discussion should belong on the new XMLCERT list (archive at http://jcewww.iaik.at/mailarchive/xmlcert/xmlthreads.html). I'm copying this initial note to other relevant lists as xmlcert is very new but I suggest people really interested would follow up there. Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com
Re: GPS integrity and proactive secure clock synchronization
7;s why I've cc:ed their CTO on this message... Some thoughts on research directions: Can we design a way to authenticate GPS-like systems without requiring globally shared keys? Notice, signatures are difficult at 50bps, and also - applying authentication codes to the sequence is not necessarily sufficient as they sequence's main function is synchronization. Can one analyse a design which will involve communication between GPS receivers using local (wired or radio) communication which will provide `real` anti-spoofing (notice my criticism of the use only of encryption of the p-code for anti-spoofing)? Can we reverse the roles here... and use highly secure time services (thru wired sources) to detect tampering with GPS signals (also for location???) It seems an interesting and challenging area. Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com
Re: GPS integrity
Thanks to Eugene and Ian... but... I'm afraid Dorothy's note is just a brief discussion of the potential applications of SmartLocator. SmartLocator is/was a product/prototype of International Series Research Inc., around 1996; I haven't found any more info about it (further to Denning's note) and suspect it doesn't exist anymore. In any case, based on what I've read in Denning's article, I think SmartLocator does not claim to secure GPS integrity. SmartLocator claims to provide a `location signature` using GPS, that is, a way to prove that the sender of a message has a GPS receiver in a particular position in space and time. Actually, this could indeed be quite useful, if this works, so one wonders how it worked and why one (me) never heard of it so far. Maybe someone on the list knows better? Or maybe we should look for a patent. Frankly: my expectations are low, I will be surprised if this was really done securely. Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com Eugene Leitl <[EMAIL PROTECTED]> on 05/09/2000 12:10:27 AM Please respond to Eugene Leitl <[EMAIL PROTECTED]> To: Ian BROWN <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Amir Herzberg/Haifa/IBM) Subject: Re: GPS integrity I presume the paper in question is http://www.cs.georgetown.edu/~denning/infosec/Grounding.txt Ian BROWN writes: > Dorothy Denning wrote an interesting paper on authenticating location using > GPS signals... I think it's reachable from her home page as well as the > following citation: > > D. E. Denning and P. F. MacDoran, "Location-Based Authentication: Grounding > Cyberspace for Better Security," Computer Fraud and Security, Feb. 1996 > > Ian :) >
GPS integrity
I'm looking for info on GPS security, specifically, its integrity / authentication mechanisms to protect against spoofing. This is important since many systems assume GPS is a secure source of time and location. (My interest in this began as we are completing paper on proactive secure clock synchronization, and figured we ought to compare this to the approach of using GPS receivers to provide secure time.) As recently discussed on this and other lists, the accuracy of commercially available (civilian) GPS has recently been improved by the removal of the Selective Availability degradation of the Coarse Acquisition (C/A) signal. However, after (very limited) digging up some GPS papers/web sites, I didn't find any mention of authentication/integrity/anti-spoofing mechanisms to the C/A signal. I did find a brief mention that the (still encrypted) P/Y signal has some anti-spoofing mechanism; but I didn't see any details on how that is done (such details may be confidential). I'm interested in both the C/A and the P/Y integrity mechanisms. The anti-spoofing of the P/Y signal is, to me, more of academical interest. I find the C/A signal integrity more interesting as it is available for commercial use. How hard is it to spoof it? Is there any real difficulty in protecting its integrity ? Or is it protected well? Thanks for any help/info. Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com
Re: time dependant
I think the secret sharing direction as Raph has described below is indeed the most reasonable way to solve this problem. In fact, for a long time, I've considered such a `secure long term archive` one of the important applications to the work we've been doing on Proactive security, which takes secret sharing forward by periodically refreshing the shares. (BTW, this is where I have a huge problem with Cryptonomicon!!) Here are some relevant works: For reference to most works on proactive security see our `proactive security homepage` at http://www.hrl.il.ibm.com/Proactive/index.html. For an easy overview see R.Canetti, R.Gennaro, A.Herzberg and D.Naor. Proactive Security: Long-term protection against break-ins. CryptoBytes RSA Laboratories Newsletter, August 1997. To see how to keep the clocks synchronized in such mobile adversary setting... ask me, it's a new result and we haven't put in the site yet - hope to do it soon to see how to keep the storage requirements reasonable see: Krawczyk, H., "Secret Sharing Made Short" Advances in Cryptology -- CRYPTO 93 Proceedings, Lecture Notes in Computer Science Vol. 773, Springer-Verlag, D. R. Stinson, ed , 1993, pp. 136-146. Krawczyk, H., "Distributed Fingerprints and Secure Information Dispersal", Proceedings of the Twelfth Annual ACM Symposium on Principles of Distributed Computing (PODC'93), 1993, pp. 207-218. here are two papers addressing exactly the time-release crypto problem: M. Kudo, "Distributed Time-Key Cryptosystem By Using Three-Party Timestamping Protocol," IBM Research Report, RT5141, 1998. http://net55.trl.ibm.com/kudo/Publication/ResRep1/crypto.pdf Note: I hope the above URL is on the Internet and not our Intranet... also I believe Kudo-san and collugues have a follow on paper in which they actually claim proactive security but I need to dig this up (it appeared in some crypto conf in Singapore very late on 1999, not CCS, was it AsiaCrypt?) I'm copying Kudo-san so he can send us (or at least me the exact reference... Conditional Oblivious Transfer and Timed-Release Encryption Giovanni Di Crescenzo, Rafail Ostrovsky, and S. Rajagopalan Computer Science Department, University of California San Diego, http://www.argreenhouse.com/papers/rafail/42.ps Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL Raph Levien <[EMAIL PROTECTED]> on 08/03/2000 00:09:11 Please respond to Raph Levien <[EMAIL PROTECTED]> To: "Cryptography" <[EMAIL PROTECTED]> cc: "Arrianto Mukti Wibowo" <[EMAIL PROTECTED]> (bcc: Amir Herzberg/Haifa/IBM) Subject: time dependant mukti wrote: > I want to know whether there is a crypto building block which doesn't allow > someone to open an encrypted message before a certain date. The way I'd do this is to split up the encryption key with a shared secret scheme, then give the shares to a number of trusted third parties, who agree to release the shares at the agreed-upon time and no sooner. If they all decide to cheat on their agreement, then you lose, although if the fraction over your threshold decide to stay honest, then you win even if the rest cheat. It sounds like there might be a business in this. It's relatively straightforward to implement, and there don't seem to be any excruciatingly difficult issues of trust and policy, just whether or not the trusted third party is going to follow the agreement. Raph
IBM Micro Payments available for (free) trials
(please excuse cross posting and semi-commercial contents - I believe this would be of interest to readers of this list) Alpha version of release 1.3 of IBM Micro Payments is available. You can read information, try out the demo, and download the servers from http://www.ibm.com/software/webservers/commerce/payment/mpay (skip the `mpay` to see our total payments line). We'll be looking forward to your feedback. IBM Micro Payments allows selling content and services for small amounts, which cannot be handled efficiently using credit cards. Its main properties are: Secure `click and pay` UI - user also know that he'll pay (and how much), yet needs only one `click` Interoperability among many providers of the system such that a buyer with agreement at one provider can buy from a merchant with agreement with another provider. Support for autmoated, invisible currency conversion. High security against fraud using efficient digital signatures. Very thin (under 200KB) and trivial install, yet full functional, client wallet (we can also support `wallet server` but that has many disadvantages, so the thin client is preferable). Open interfaces, support for standards etc. - in particular we are the first implementation of the W3C Micropayments Markup spec Our approach is to make the software widely available thru partnerships with ISPs, telcos, banks, processors - as well as OEM channels. Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL
Re: Internal vs external threats, any references?
Rick said, > One has to be careful with one's universal quantifiers. > > "There's no attack you can defend against." - false > "There are defenses against some attacks." - true > "There are defenses against all attacks." - false > > My own experience makes me skeptical to the point of incredulity when > someone claims to be invulnerable to viruses and trojans. One can defend > against limited cases at best, and defenses get stretched to the breaking > point as time and technology move on. Agreed, but, I think we can still do something to better protect our systems in this networked world. Specifically, we should take advantage of the fact that most systems and services can be provided by a collection of several servers. Then, we can use distributed or proactive security to improve the security of the entire system, in spite of break-in to some of the servers (or, with proactive security, even to all servers - but not at the same time). Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL Rick Smith <[EMAIL PROTECTED]> on 05/10/99 23:48:24 Please respond to Rick Smith <[EMAIL PROTECTED]> To: Ben Laurie <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] (bcc: Amir Herzberg/Haifa/IBM) Subject: Re: Internal vs external threats, any references? I said: >> If it's programmable it's vulnerable. Ben Laurie replied: >Oh, right. There's no attack you can defend against, right? One has to be careful with one's universal quantifiers. "There's no attack you can defend against." - false "There are defenses against some attacks." - true "There are defenses against all attacks." - false My own experience makes me skeptical to the point of incredulity when someone claims to be invulnerable to viruses and trojans. One can defend against limited cases at best, and defenses get stretched to the breaking point as time and technology move on. Rick. [EMAIL PROTECTED] "Internet Cryptography" at http://www.visi.com/crypto/
Re: Internal vs external threats, any references?
Jeff says/asks, > A commonly-held conception in the commercial world (in my experience) is that > most threats to "corporate security" come from the Internet-at-large, and > therefore being behind a firewall is a Good Thing and generally Sufficient. I believe this is a very wrong notion. However I want to point out that even if one is concerned only/mainly about external threats, a firewall is still only a very limited solution. In fact, I believe firewalls are no match for a determined attacker, for the following simple problem with the firewall approach (rather than with a specific one): firewalls cannot prevent a program running on the internal network from bypassing it. Now, getting one program to run in one computer within an organization is fairly easy - any good trojan horse or virus can do this. So, a determined attacker can by pass any firewall - and organizations should use additional tools to defend. (and this time I'll stop here :-) > Of course there are many references in the literature which dispute that > one-sided posture, and it is a reasonably commonly-held (again in my > experience) amongst security weanies that just as many if not more threats may > emanate from within one's organization (a university being an canonical > example), but I haven't uncovered any references that directly cite evidence > quantifying this perception. I actually remember there being some numbers but I'll have to leave the quote to these with more stable memory (chips?)... Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL
Re: Ecash without a mint, or - making anonymous payments practical
Steve takes an issue with me for my belief that anonymous payments will involve overhead that may make them less popular than non-anonymous payments. He says, > There is no reason to expect anonymous system will be more expensive than > the current book-entry variety, in fact quite the contrary. Of course, it doesn't make any sense that adding any requirement, esp. a non-trivial one such as anonymity, will result in a less expensive system. In particular anonymity does not remove the technical requirements of book-keeping to prevent duplication. But, I don't see the point in arguing about this. Let us implement the best systems - with and without anonymity - and then compare. Again: I'm _not_ against anonymity, on the contrary (even done a bit of research in this area). However my main goal is to facilitate commerce in digital goods and services. I think this is a difficult goal as it is without adding the anonymity requirement. I feel better knowing that this will not prevent anonymity solutions, since the hybrid approach allows them to be an extension of the basic payment scheme. One small final comment: physical cash is not really anonymous (bills have serial numbers, and certainly coins may contain secret marks. Why? Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research - Haifa Lab (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL
Re: Ecash without a mint, or - making anonymous payments practical
Anonymous says, (btw, I really wonder what's the point of having a technical discussion incognito... I hope this is not for a really good/bad reason such as you are living in some dark country), > Hmmm... sounds like you are saying that if you had an anonymous payment > system you could use it to buy "checks" in your non-anonymous system. > But if you already had the ability to make anonymous payments, why bother > with your system? I can go to the bank and buy a cashier's check for > cash, then make a payment with it, but I could just as easily have paid > with cash directly. There are two reasons. First, as you say below, there is simply the reality of there being multiple systems. Second, and more essential, there are some important advantages e.g. in efficiency to non-anonymous payment mechanisms. BTW, non-anonymous here does not necessarily mean `identity-based`, but rather, payment mechanism which do not offer complete, secure anonymity. The problem is of course that if such non-anonymous payment mechanisms are common, it may become difficult to convince merchants to support also an anonymous payment mechanism (with relatively few customers - assuming most customers will not be willing to `pay` for the anonymity). Furthermore customers choosing the anonymous mechanism may attract attention to themselves (I guess the use of `anonymous` for e-mail is a good example!). So I think my simple hybrid proposal makes sense. > Of course in practice it is helpful to have money changers who can > convert between different payment systems, since there are so many > competing proposals in the world. Agreed. > > We actually will have the necessary APIs in merchant and buyer to allow > > integration of such an anonymous payment mechanism with the next release > > of IBM Micro Payment (1.3, next month). We may later on implement this > > ourselves if customers are interested, but frankly I prefer to see others > > implementing it; for one reason, as you know, there are multiple patents > > regarding anonymous payments, so it will be a pain to do this (in IBM). > http://www.ecoin.net/mmdh is a project based on Wagner blinding which > is thought to escape patent protection. Perhaps this would be a good > starting point for a blind payment system. Are your APIs going to > be public? Thanks for the pointer. Of course, as long as the anonymity is provided by somebody else, I don't need even to worry about the patents... so much the better... And yes, of course we're going to publish our APIs. We actually published also the APIs for version 1.2 (see the manuals in our site) but then, version 1.3 is almost a complete re-write of the system and in particular we've dramatically improved the APIs - so better wait for them. We hope to be able to publish them in time for the IETF BOF on Micro Payments (BTW I'm still looking for presentations and interest in this event - let me know if you want to present, or event just confirm to me that there is interest in the BOF and in at least us proposing our protocols). Discussions of the BOF are in [EMAIL PROTECTED] Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research - Haifa Lab (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL Anonymous <[EMAIL PROTECTED]> on 24/09/99 00:44:47 Please respond to Anonymous <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], micropay@IBMIL cc: (bcc: Amir Herzberg/Haifa/IBM) Subject: Re: Ecash without a mint, or - making anonymous payments practical Amir Herzberg says, > Anonymous says, > > > It is still worth considering how to create anonymous payment systems > > which could be more compatible with other elements of present day society. > > I think we can do this, indeed, we can achieve an even stronger goal: > a payment mechanism that will support anonymous payments for people > so wishing, while allowing other people to use non-anonymous payments > (which will always have some advantages), without allowing merchants to > identify the anonymity-seekers. Yes, of course you could add identification to an anonymous payment system simply by having people reveal their identities. Anonymity infrastructures offer users the option to hide their identities, but they can't stop people from revealing pseudonyms or true names. > The method is simple and can use any anonymous payment mechanism. Consider > for simplicity a buyer, seller and a billing server (payment system > provider - bank, telco, etc. - `billing system` is the term we use > for this party in IBM Micro Payments). The payment system supports > pre-certified payments, which are payments (to the seller) signed > directly by the bi
Re: Ecash without a mint, or - making anonymous payments practical
Anonymous says, > It is still worth considering how to create anonymous payment systems > which could be more compatible with other elements of present day society. I think we can do this, indeed, we can achieve an even stronger goal: a payment mechanism that will support anonymous payments for people so wishing, while allowing other people to use non-anonymous payments (which will always have some advantages), without allowing merchants to identify the anonymity-seekers. The method is simple and can use any anonymous payment mechanism. Consider for simplicity a buyer, seller and a billing server (payment system provider - bank, telco, etc. - `billing system` is the term we use for this party in IBM Micro Payments). The payment system supports pre-certified payments, which are payments (to the seller) signed directly by the billing server. In this case, the buyer's identity obviously does not need to appear in the pre-certified payment (it is simply a payment - like a check - from billing server to seller). So all the buyer really does is `buy` this pre-certified payment. Now, obviously, if the billing system allows, the buyer may use anonymous payment protocol to buy the pre-certified payment, in which case (and assuming all communication is anonymized) we have complete anonymity (from billing system and from seller). We actually will have the necessary APIs in merchant and buyer to allow integration of such an anonymous payment mechanism with the next release of IBM Micro Payment (1.3, next month). We may later on implement this ourselves if customers are interested, but frankly I prefer to see others implementing it; for one reason, as you know, there are multiple patents regarding anonymous payments, so it will be a pain to do this (in IBM). Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research - Haifa Lab (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL
secure (proactive?) clock synchronization
We've been recently working on what seems like a neat new clock synchronization protocol, which will hopefully offer proactive security (recovery from penetrations, see http://www.hrl.il.ibm.com/proactive). Surprisingly, it also appears a very practical protocol. It has been some time since I last worked on clock synchronization, so I wonder, what is the state of the art - practical protocols (any substantially change in NTP recently or any serious alternative), and protocols designed to withstand attackers (of course I'll be esp. interested if there's anything with some recovery properties!!). Thanks for any pointers. Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research - Haifa Lab (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL
Assigning Roles to Strangers
We are investigating the use of public key certificates, either x509, SPKI or other, to establish trust among two `strangers` (parties without a prior long term relationship). We will appreciate any feedback, and are looking forward to serious parties interested in pilot deployments. Please see our site http://www.hrl.il.ibm.com/TrustEstablishment, and in particular the paper: Access Control Meets Public Key Infrastructure, Or: Assigning Roles to Strangers Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research - Haifa Lab (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL
another small comment on: Five years, and still no useful internet cash
I just looked a bit to see other schemes in Jim's page and was surprised to find: > Internet Keyed Payment Protocols (iKP): Open definition, but no open source. Largely a public statement of what is in the wholly >proprietary code (IBM Micro Payments) rather than a genuinely non proprietary protocol. Just to clarify: of course I was of the (key?) designers of iKP... and of course in IBM Micro Payments I used many things I learned from the work on iKP - and on SET, the credit card standard, which is really an enchanced (too much?) version of iKP. But there are many differences between the two as iKP was really just a credit card protocol. In our site you can find papers and presentations with much more details on IBM Micro payments... Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research - Haifa Lab (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL
Proactive Security Home Page
Proactive security allows recovery from penetrations and exposures of secret keys. We have been working in this area for a while (initiating it, I think), and recently, we are working on a toolkit to allow applications to take advantage of proactive security - should be made publicly available later this year (August, we hope). We've made a `homepage` for proactive security, where you can see information in general and on the demo (architcture and screen shots only at this point). This site is at http://www.hrl.il.ibm.com/proactive/ Your comments (on the page, our project, or proactive security in general) are most welcome. Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research - Haifa Lab (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: [EMAIL PROTECTED] New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL
Research positions in crypto and e-commerce
[A long time ago I adopted the policy of forwarding these if they looked sufficiently interesting to the readership -- I think this is. --Perry] This note is to solicit applicants to positions in the E-Business and Security Technologies group of IBM Research. The group is located in Tel Aviv, Israel; organizationally it is part of the IBM Haifa Research Lab. I appreciate your understanding and support in forwarding this information to potential candidates. The E-Business and Security Technologies group is doing innovative applied research in advanced areas of e-commerce, security and knowledge management and collaboration. Our approach is to focus on areas where we can make maximal contribution and impact, by creating, promoting and using open software and standards, such as Java and XML. Examples of our work include IBM Micro Payments and Proactive Cryptography/Security; for more information see http://www.hrl.il.ibm.com We now have openings for regular and temporary (summer, postdoc) positions. To apply please send me ([EMAIL PROTECTED]) e-mail with your CV (prefer in HTML or plain text), and what kind of position you are interested in. The specific positions we look for are: 1. Cryptographer (regular employee, post-doc and summer student positions): a CS graduate (PhD preferred) with specialization in cryptography and/or network security. The initial assignment will be analysis and design of proactively secure cryptographic mechanisms, and guidance in cryptographic aspects to the implementors of the proactive security toolkit (see more info in http://www.hrl.il.ibm.com). Familiarity with Java, C++ and TCP/IP programming will be an advantage. 2. E-Commerce and Web specialist: an expert CS (or similar) graduate (PhD preferred) or exceptional bachelor, with demonstrated ability to do innovative research in Web technologies and in particular in the areas of E-Commerce, knowledge management and collaboration. Knowledge of at least one of Java or C++ is essential. Candidate will join one of our projects developing advanced application-enablers in these areas. To see more positions in IBM Research: http://domino.watson.ibm.com/hr/research/resumes.nsf/Employment/Job+Listing s?OpenDocument Thanks, Amir Herzberg Manager, E-Business and Security Technologies IBM Research - Tel Aviv site of the Haifa Lab http://www.hrl.il.ibm.com Fax 972-3-691-4736
Re: New Version of the AES Peformance Comparison Paper
Bruce, thanks! Very useful and well written! Also: it would be nice if we also had comparisons to DES and TripleDES just for completeness (of the speed and RAM requirements). One question: the performance figures seem very close to these at http://www.seven77.demon.co.uk/aes.htm - except for Twofish... Can you confirm/clarify? Thanks, Amir
comparison of fast encryption mechanisms and AES proposals
Following Bruce's announcement - I wonder, if anyone has/knows a high-level comparison of different high speed encryption algorithms and esp. AES proposals. Thanks, Amir Herzberg
Preparing course `Intro to crypto with focus on e-commerce applications
Hi, I'm preparing a course for CS undergrads on `Intro to crypto with focus on e-commerce applications`. I plan to make computer foils and later make them available. This is not an easy task of course (that is, it takes some time), so, I'll appreciate any pointers to good available foils or really good lecture notes (I did look up Rivest's, for example). Thanks, Amir Herzberg
