 |
privacy |
||
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2005-04-28A Secure RFID-Identification Protocol?ACM News Service: Feds Rethinking RFID Passport. As noted by Bruce Schneier as well, the International Civil Aviation Organization has come up with a Basic Access Control protocol for security of RFID chips and their contents in passports. The US State Department is considering adoption of the approach in response to public comments and realization that RFIDs may be readable at greater distances than intended. This seems to involve a challenge response scheme using physical information on the passport folder as part of the conditioning scheme. The BAC seems to operate as follows:
Kim Zetter’s 2005-04-26 Wired News article has more information including links to a number of papers on the specifications, trials conducted with BAC-implementing devices, and an analysis that identifies some weaknesses. The article indicates that BAC has been tested and done well, other than for the slowness introducd in the use of cryptography. There are also some defects in the scheme, but these are not thought to be critical. It is the case that the RFID is presumed to be read-only, and PKI techniques are used. The basic concern of the comments on Schneier’s article seems to be that even transmitting an encrypted response reveals too much about the bearer. Simply obtaining the RFIDs pong may reveal all the information that a terrorist needs. And other out-of-band failures may occur, such as timing attacks and related ways of gaining enough information to carry off an exploit (including the ultimate denial of service, death of the bearer). Secondly, if there is no shared secret, the contents of the RFID message can be obtained by a replay attack. Based on my sketch, above, derived from a quick review of the available documents, this is not so likely if the recommendations made in the defect analysis are instituted, including having the RFID generate session UIDs via some random scheme. The recommended precautions in an undated analysis by Juels, Molnar, and Wagner seem reasonable to provide in the case of US passports and entry to the US, because the US scanners will have the prerequisite capabilities. I have the sense that not all passports need provide the maximum set of security provisions, and not all readers need demand them. The minimal case is use of the physical passport and its markings and enclosures alone. One concern of the authors of the weakness analysis is not the limited application of the scheme for passports, where it seems to be reasonably well-suited. They express concern over function creep and application of the scheme in other settings where there can be unintended consequences of threats and interactions not foreseen for the ICAO use case. If P(RFID) can be altered—for visa information, say—there are new difficulties to consider.
2005-04-26How Effective Is Your Software QA?ACM News Service: Survey – Formal QA Process Key to Improve Testing Results. This is a distillation of a research survey, and it is a little difficult to figure out how these things slice and dice. The bottom line is, “More than half of the 129 execs who rigorously adhere to a formal QA discipline said such a strategy was very effective at winnowing out defects prior to implementation.” To put this in some sort of perspective, “about two-thirds of the 32 percent of respondents who saw massive gains in application quality consistently apply a formal QA plan.” Kathleen Ohlson’s 2005-04-18 Application Development Trends article mixes in more of these weird statistics. [dh:2005-04-27T01:14Z A quick update to provide a title and let you know what the article is about without having to read it first.] An Entirely New Way of Designing Systems?ACM News Service: Cyber Security Has Its Limits. “The recent intrusion into Carnegie Mellon University (CMU) business school computers illustrates that not even top IT security institutions can completely guard themselves against cyberthreats and that an entirely new way of designing systems is needed, according to security and privacy experts.” The TRUST initiative is mentioned as a possible source of research toward a more-permanent solution to these kinds of problems.
Trust Points and Trust IssuesACM News Service: A Trust Analysis Methodology for Pervasive Computing Systems. In analyzing the trustworthiness of software, I notice that there are trust surfaces and trust points—places where there is an (usually-tacit) assumption of trust in some service or resource being relied upon. While I am struggling to formuate something crisp in this area, this approach comes to my attention. The ACM TechNews blurb summarizes an approach to trust analysis that identifies a grouping of trust-issue categories:
The work of Lo Presti, Butler, Leuschel, and Booth is a chapter in a Springer Lecture Notes publication, Trusting Agents for Trusting Electronic Societies. A PDF of the chapter is available as an EPrint of the University of Southampton. There are valuable references and consideration of trust metrics in a five-stage Trust Analysis Methodology. I’m not sure the methodology works in the context of my TROSTing effort, but the overall model and consideration of the categories of trust is extremely valuable to build on. The book also has an interesting article by José M. Vidal on distributed recommenders and there are contributions by Leon van der Torre . The AgentLink effort has some material on trust related to agent technology. 2005-04-24How Do We Safely Orient for Aspects?Slashdot | Aspect-Oriented Programming Considered Harmful. My first exposure to AOP was in the way that Kiczalis talked about having implementations be exposed in an appropriate way beneath or on the side of abstract interfaces. I thought of this as an interesting idea for optionally, conditionally, and dynamically optimizing an integration of components without torpedoing the abstraction. My mental picture was always anchored to the prospects of a nice fit with something like the IUnknown::QueryInterface provision of COM components, and I often find applications that take that form in crafting interface-based component frameworks. Later, I read that AOP is about cross cutting, a much more difficult notion. The idea is appealing, and I think of it as useful in terms of multiple patterns and architectural perspectives across a single system. The trick, if I understand it, is in maintenance of aspects such that they are each dealt with in their own locality and as separated concerns, yet the implementation must have accommodation of each aspect distributed among its objects such that the aspect is realized and the objects integrate properly. That's my basis for wondering what this cautionary analysis is all about. The notion of aspects is very compelling, but maintaining a coherent integration of objects that honors multiple aspects seems difficult and also not something done light-weightly. I'm not concerned so much about this to pay $50 per page for the Forrester report, and I can't confirm nor deny the relationship to the "fragile pointcut problem" in the work of Maximilian Stoerzer and Christian Koppen. The analogy with the harmfulness of "Go To" (and the need for a kind of "come from," arguably even more harmful) is interesting though. The advantage of the structured-programming model was that it was possible to inspect a local part of a program and see all of the control relationships and only the control relationships that had any bearing on that structural element. (We still had to cope with assignment-statement considered harmful, but great progress was made just the same.) My initial, simplistic understanding of AOP doesn't change that. The cross-cutting idea does, in that looking at a locality doesn't necessarily present all of the interactions and dependencies, and those can be changed without any indication in the piece of program you are looking at. Somehow, divide-and-rule must be preserved in a way to avoid difficult, brittle situations. It would appear that is indeed the challenge and the current AspectJ point-cut approach leaves much to be desired. You can look at the fragile pointcut as an exception that can return control, and in the general aspect-oriented case, the rule for throwing the exception might not even be visible in the code under examination. This challenge has me rethinking exceptions that can return control, too. In regard to trustworthiness of code, I now realize that I must be leary of languages that don't require accounting for exceptions with something like strong typing and explicit declaration, too. I think the cross-cutting notion of aspects is of great importance in software engineering and in the pattern and design level. I am not so sure that we have figured out how to carry it down to the maintained form of the code in a non-brittle way. At this point I must plead ignorance and remain alert for more contributions on the topic. |
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |