|
|
Friday Jan 23, 2009
Rollercoaster week & last post
Copied from my now only blog: http://blog.beuchelt.com/
It was great at Sun - good luck to you all!
Gerald
Wow - what a week this was... I have been through quite some ups and downs, and that is not even mentioning the fact that the U.S. got a new
administration.
Bad news first: not only did I have a mild
form of food poisining (not that there was anything 'mild' about it,
but I heard it can be much worse), but I am also affected by the
workforce reduction at Sun. Yes, that's right... after a meager 11+
years I am on to new adventures elsewhere. To all those that I have
been working with: it was a very interesting and mostly fun ride. I
really had a sense of being able to work on something big and
accomplish a lot, but the energy and the creativity at Sun was very
inspiring. I met a lot of smart people there, and I hope that I will
have the chance to continue working with them, one way or another.
Going
forward, I see myself continuing on the themes that I have been dealing
with for a while now: interoperability, web-centric (now cloud)
computing, and the related identity and security aspects. There is a
lot of work ahead, and I am quite determined to continue contributing.
Since
my age-old email at Sun will cease to work soon, you will now be able
to reach me though an interim alias: work-at-removethispart.beuchelt.com[1]. I am also on Facebook and LinkedIn, so please feel free to connect with me:
http://www.facebook.com/people/Gerald-Beuchelt/615829807
http://www.linkedin.com/in/beuchelt
With
more time on my hands for now, I will also start spamming your RSS
readers... just kidding - but I will write more here now, so stay
tuned.
But now for the good news: yesterday my application
to become a U.S. citizen was approved and - assuming all goes well - I
will take my Oath in early March. Contrary to its horrible reputation
my experience with USCIS (formerly INS) was actually quite good: yes,
they are bureaucratic (you should have seen the piles of files they had
on me), but overall the process was quite efficient and fast: it will
have taken less than 6 months from sending in the application to my
Oath ceremony.
Interestingly enough, my becoming a U.S.
citizen will also open new doors on the job market: as of March I will
be able to get a security clearance, work on certain government
contracts, etc. The timing could not have been better.
tags:
identity management naturalization workforce reduction [1]Sorry for putting the "removethispart" subdomain in - obviously it is only beuchelt.com after the @ sign.
Posted at
02:09PM Jan 23, 2009
by beuchelt in General |
Tuesday Sep 02, 2008
Google's Path to World Domination
No, I am not talking about Google Chrome (yet). But it is related: if you look at
it
seems that Germany has already conquered Denmark, Benelux, Switzerland,
and Austria-Hungary. It could also be a the EUSSR with its capital in
Brussels...
Or maybe this is a completely new country call "Googleland", where
every citizen deposits all their data in a save datacenter, identified
by a unique id. "Information Self-Determination" is a basic human
right, and any data merchant will get shot on sight.
The only
exception is the operator of the datacenter (that would be Google,
being compensated for their services by an unalienable right to use any
of the data for targeted advertising campaigns), or any data thief that
offers information on citizens suspected of being involved in
terrorism, sedition, or tax evasion.
humor privacy google chrome
Posted at
11:02AM Sep 02, 2008
by beuchelt in General |
Tuesday Aug 12, 2008
Freedom of Press? In Massachusetts? Nah ...
This is just another installment of how the freedom of expression and scientific research is being sacrificed on the altar of "public safety" and "property rights". From the CNET article:
"A federal judge on Saturday granted the Massachusetts transit
authority's request for an injunction preventing three MIT students
from giving a presentation about hacking smartcards used in the Boston
subway system."
To summarize this incident: a couple of student find a giant security hole is a publicly financed payment system. They inform the authorities and involved parties to given them a change to work on the situation. The faceless bureaucrats respond in the way any large (and thus inefficient) organization will respond: ignorance and disbelief. The students follow the time-honored tradition of publicizing their results and suddenly the gears spring into actions: federal courts, FBI, and preliminary injunctions appear. The official reason is "public safety", but everyone involved knows that this is just a very lame excuse. In truth, it is the desire of an inadequately powerful state-sponsored enterprise to hide their incompetence and silence their "subjects".
The fact that this can even be done is the availability of unconstitutional laws (at least in spirit) like the DMCA and similar utterly meritless legislation. Coming from Europe, I am used to the frequent oppression of freedoms, even today. So far, the U.S. has been setting an example of how e.g. the freedom of expression should be interpreted. This gag order by a federal judge in Boston (sic!) is an untenable limitation of this right. It goes against some of the most fundamental principles enshrined in the Constitution and the Bill of Rights. For more information, check the EFF website. tags: civil rights, freedom of speech, mbta 
Posted at
03:09PM Aug 12, 2008
by beuchelt in General |
Monday Aug 11, 2008
Giving credit where credit is due ...
I just laughed out loud:
Go King Homer I. of Spain!
tags: humor, simpsons 
Posted at
05:20PM Aug 11, 2008
by beuchelt in General |
Securing OpenID@Work - Again
Last year we announced an experiment at Sun: in order to gather
more information about the operational characteristics of
"user-centric" identity technologies, we decided to roll out an OpenID
provider for Sun employees. This OpenID provider was intended to be
used by Sun employees for personal usage at various OpenID sites that
have been popping up at some places.
This experiment involved various parts of the company, including
field people, products folks, the security team, and our Chief Privacy
Officer. We negotiated a number of requirements for our experiment:
employee privacy must be maintained at all times, the system must not
interfere with any other Sun authentication or business system, etc.
All this was quite achievable and we passed the--albeit lax, since it
was an experiment--security and privacy reviews, the focus of which was
the protection of Sun employees and property.
The weakness in Debian-generated certificates and the recent DNS
cache poisoning attack vector resulted in a triple whammy: weak
certificates, broken DNS, weak protocol. After Ben's report last week,
we revisited the current design of the service and came up with a few
recommendations. Mark Wilcox notes that my list could be hard to follow, especially for non-technical users. To some extend[1] I do agree with him, so we decided to take additional steps on our end to improve security:
The very core of these changes lies in the idea that we are
introducing HTTPS based OpenIDs for our users. In OpenID 1 and 2, a RP
normalizes any identifier without scheme prefix into an unsecured HTTP
based identifier. Only a prefixing the OpenID identifier with the
https:// scheme will result in discovery over an TLS secured transport
channel. This looks a lot "geekier" than the somewhat more appealing
"naked" OpenID identifiers, but as a result of this change, the lookup
will now be handled completely over server-authenticated channels. In order to make this approach useful, we would need the cooperation of OpenID RPs: in the current specs, http://openid.sun.com/user and https://openid.sun.com/user are two separate entities, which--in my opinion--makes no sense. If RPs would start recognizing these two identifiers as the same entity, it would help improve the security of the OpenID protocol in a quite significant way, since users could easily migrate from the broken insecure HTTP discovery protocol over to the somewhat more secure HTTPS transport.
Obviously, this cannot address the key-reandomness weakness, but
then ... only time can. Meanwhile we have to rely on CRLs and OSCP
checking for certificate revocation.
UPDATE: The approach outlined above might be criticized for equating two URI that are not equivalent (https://... and http://...). I appreciate this from a principal point of view, but extreme time require extreme measures ;-).
A reasonable way to address the potential security implication for current https://.. identifiers would be for the RP to perform a one-time security upgrade: assuming that the RP recognizes a particular claimed_id e.g. http://openid.sun.com/user. Whenever there is a login with the same identifier over HTTPS (i.e. claimed_id is https://openid.sun.com/user in the example), the RP can 'upgrade' the account to an HTTPS-only account.
On the OP side, any account for https://x.y.z should trigger the complete block for any http://x.y.z ids.
Thanks to John Bradley for some stimulating discussions on these issues.
tags: OpenID security transport security
[1] Mark mentions OAAM's strong authenication and risk based authentication technologies as potential solutions for OpenID's weaknesses. Maybe it is because I am not familir with this product, but I cannot see how OAAM can help with the weaknesses that occur through using HTTP (as opposed to HTTPS) for discovery. Likewise, socially engineered attacked can be effective in circumventing stronger authentication mechanisms (such as pictures or virtual keyboards) for less technology-sophisticated users: instead of their image, the rogue OP displays an error message along the lines of "Sorry, your personal image is currently unavailable due to maintenance. Please use standard authentication in the meantime." This might not work with all users, but I know enough folks who would login also with the "standard authentication" scheme.
Posted at
02:06PM Aug 11, 2008
by beuchelt in General |
Thursday Aug 07, 2008
Some security advice for our OpenID users
With the recent news about the DNS cache vulnerability, users are more exposed
than ever to potential security attacks, including phishing or pharming attacks,
that apply to OpenID as well as other network systems. For example, the ability
to redirect DNS requests through cache poisoning opens the door to a significant
OpenID security risk: if the OpenID provider is not employing TLS with
server-side authentication — preferably mutual authentication — any affected
DNS server could redirect the client to a pharming site that looks like the
user's real OP, but is not. If OpenID required transport and authentication over
HTTPS, this would be less of a problem.
In order to limit the risk, we are advising the users of our OpenID@Work
provider to make sure that they follow these guidelines, which might be useful
for others, as well:
- Make sure that you systems are fully patched.
- Verify that the DNS server you use (usually provided by your ISP) is
patched and not subject to DNS cache poisoning. You can verify this at Dan Kaminsky's web site. If you find that your ISP has not down their job, complain. Loudly.
- Use certificate revocation lists. These list contain the serial numbers of revoked certificates and they can be easily consumed by most modern browsers. For the SunPKI list, just point your browser to http://www.sun.com/pki/pkismica.crl and make sure that your browser refreshes it regularly. Other companies have their own CRLs (e.g. Verisigns are here).
- Be extra careful when accessing your authentication web site: openid.sun.com can easily be mistaken for open1d.sun.com or openid.sun.com.uk.
In addition, we recommend that Sun employees use the corporate VPN for all
sensitive corporate business, and — obviously — not use the experimental
OpenID@Work authentication service, or any OpenID authentication service, for
anything of value. UPDATE: The Sun PKI CRLs is also here, which is the official distribution point for Sun/Verisigns issued certificates. In addition, these certificate support OCSP verification at http://ocsp.verisign.com.
Ben Laurie and Robin Wilton also published information relating to the weaknesses of OpenID.
tags: openid dns cache poisoning security 
Posted at
02:18PM Aug 07, 2008
by beuchelt in General |
Friday Jul 25, 2008
A patently good idea
The U.S. Patent and Trademark Office (USPTO) is considering to invalidate many (if not most) software patents and significantly restrict the issuance of new process patents. No doubt, intellectual property does deserve decent protection, and I think that this move by the USPTO will in fact result in better protection of property: copyright law provides ample protection against IPR theft while not getting in the way of real innovations. To draw a technical comparison, process patent law protects the API, while copyright law protects the implementation. Although it takes a lot of thought to come up with a good API, it should be the implementation that is at the heart of the competition to not harm the end-user.
In this sense, the new direction of the USPTO will benefit the end-users (consumer as well as application developers) by allowing the concrete implementation of ideas to compete while keeping interoperability at the idea-level intact. In the end, the entire market will benefit including the vendors by lowering the barrier for interoperability significantly. tags: internet law IPR patents 
Posted at
02:39AM Jul 25, 2008
by beuchelt in General |
Friday Jul 18, 2008
Using Abdera and the Jersey Client API
Marc recently published a short
tutorial on how to use Apache Abdera with Apache
Abdera with our reference implementation of JAX-RS, Jersey. His code is server side, i.e.
it explains using Jersey and Abdera for creating RESTful web services with
Atom payload[1]. In this article I will give an example on how the
Jersey client API can be used to consume such a service with realitve ease.
It is hopefully known that Jersey contains a very simple, yet effective
HTTP client API. Core to it is the heavy use of the builder pattern for
creating and configuring requests. For our example, I start with creating the
client:
Client c = Client.create();
WebResource r = c.resource(new URI(someLocation)); We can now get the InputStream from the WebResource to read the Atom feed
into an Abdera Feed:
InputStream is = (InputStream) r.get(InputStream.class);
Document<Feed> doc = Abdera.getNewParser().parse(is);
Feed feed = doc.getRoot();
for (Entry entry : feed.getEntries()) {
doSomething(entry);
}
Now let's say we want to post an entry to the resource in Marc's article.
In this case we would also have to use his AbderaSupport class, which
implementes the proper MessageBodyReader
and MessageBodyWriter
interfaces for the Abdera objects. On the server side providing these
interfaces is enough, but on the client side we need to configure the Jersey
client. The following code helps doing this:
public static class AbderaClientConfig extends DefaultClientConfig {
@Override
public Set<Class<?>> getProviderClasses() {
Set<Class<?>> classes = new HashSet<Class<?>>();
classes.add(AbderaSupport.class);
return classes;
}
}
Thus completing our sample app:
ClientConfig cf = new AbderaClientConfig();
Client c = Client.create(cf);
WebResource r = c.resource(new URI(someLocation));
Entry entry = AbderaSupport.getAbdera().newEntry();
entry.setTitle(...);
entry.setContent(...);
ClientResponse cr = r.type(MediaType.APPLICATION_XML).put(ClientResponse.class, entry);
Done. tags: Jersey Apache Abdera Atom JAX-RS [1] Tim pointed
out that this style should properly called "AtomPub", and not APP,
AtomPub/Sub or similar.
Posted at
06:43PM Jul 18, 2008
by beuchelt in General |
VRM Workshop 2008
This week's VRM Workshop at the Berkman Center in Cambridge, MA was quite interesting. It helped me quite a bit to sort out how Identity Management and VRM intersect, but also differ in some respect. To put it in a nutshell, I believe that the biggest difference between the two is that they are essentially two different ways of looking at the same problem. "Traditional" identity management has been focusing largely on the varies subjects (and objects), their characterization, and how they can be mapped to digital artifacts. VRM seems to be taking a more procedural approach by focusing more on the processes and interactions of these subjects, objects, and digital artifacts. In this sense, VRM and identity management are very much complimentary. You can find more information about Doc Searls ideas about VRM on the Berkman wiki and on his blog.
vrm2008
Posted at
01:15PM Jul 18, 2008
by beuchelt in General |
OpenSocial and Liberty
OpenSocial and Liberty People Services are really tackling the same problem - only from two opposing sites. While the LAP PS has established a solid foundation for secure identity management, OpenSocial has started out to define an API for allowing social networking (but also other) software from different source to be run in one (or more than one) container. Ideally, these container abstract away the underlying platform and thus enable application portability. This becomes quite useful, since facebook, MySpace, Orkut, etc. have extremely similar types of applications (friends/relationships, photo sharing, contact management, and many more). Having these applications being portable across different allows application developers to focus more on added functionality and less on platform plumbing.
Liberty - on the other hand - has created the necessary infrastructure to enable individuals to set preferences and share information about themselves with other in a secure and privacy preserving way. The protocols used in ID-WSF and people service (and not APIs) can enable containers to communicate with others based on user's policies and requests. libertyalliance opensocial
Posted at
01:09PM Jul 18, 2008
by beuchelt in General |
Monday Jun 30, 2008
High Potential?
The current economic situation is not exactly ideal: amongst many significant issues, one of the most concrete and pressing problems of today is the highly volatile energy market. Many current problem in the world (such as clean water, food, housing) could be solved almost completely, given that there is sufficient energy at hand[1]. Electric energy generation has seen a variety of approaches: some of them are quite childish, while others lack in public acceptance. Ultimately, only a sound mix of nuclear fusion and a select number of reasonable renewables such as solar or geothermal energy source (were available) will make sense. However, electricity is not particularly easy to store, making it by far less attractive for any type of transport, especially individual transport. No technology that has been available so far has created a reasonable alternative to fossil hydrocarbon fuels: they have a sufficient energy density, are easy to handle, and the technology is very well understood. Alternatives such as canola-based diesel or ethanol-enriched gasoline are mostly carbon-ineffective ways of wasting money and alimenting lobbies. Now, a new genetics based approach is making the rounds in various news outlets: LS9 is a South San Francisco company that succeeded in creating microorganisms that can produce hydrocarbons from renewable sugar sources. In other words, it will soon be possible to replace the back-yard compost heap with a small LS9 reactor that produces gasoline instead of dirt. It will be interesting to see, if this technology can actually scale to a level where a large (and energy hungry) economy such as the U.S., China, or the E.U. can rely on this renewable fuel for a significant portion of their needs. But even if this approach is not fit for mass energy production, it still guarantees the available of hydrocarbon based products (i.e. plastics) in the post-fossil age.
[1] Obviously, in today's world there is also in many cases a lack of political will, but that is - at least to some extend - again a result of scarce energy. 
Posted at
11:42AM Jun 30, 2008
by beuchelt in General |
Friday Jun 27, 2008
Review Friday: Sony XDR-F1HD HD-Radio Component Tuner
To day, I would like to take a peek at a technology that has been living in the shadows for some time. While HDTV and digital broadcast over-the-air have been getting some attention lately (especially with the January 17, 2009 deadline looming), digital radio broadcast have not been getting any significant media attention in the U.S.A.
One of the reasons for the lack of attention might be that the digital radio standard chosen by the FCC has been met with some serious criticism. The two arguments that are most profound here in my mind are sound quality and proprietariness.
Nevertheless, since I am listening to a lot of radio during the day, I have decided to give this broadcast system a try. For receiving, I chose the Sony XDR-F1HD component tuner that allows most easy integration with a standard stereo system. Connections are made simply through RCA style component wires. The system comes with an AM and FM antenna cable, but standard connection (e.g. to you home TV antenna) are available. The unit is very simple to configure and has - in addition to the radio program information - a large clock. The display is illuminated.
Reception of FM HD radio stations is - overall - pretty good, even under adverse conditions. My antenna is setup inside the Sun office, which is a steel reenforced concrete building with excellent radio shielding qualities (sigh!). In addition, the indoor antenna cable is close to two CRT monitors and a variety of transformers. Most strong stations (such as WGBH) are readily avilable with little or no reception problems. However, AM reception is rather spotty and so far I have only been able to receive WBZ when holding the antenna at 83 degrees North-North-West about 3'7" above my desk.
The sound quality is most of the times acceptable. The radio signal codec is a proprietary version of the AAC encoding, encoded at 36 kbit/sec. This is far from being CD quality, but it does remove the noise floor of the FM signal to a large extend.
Overall, I would probably recommend this setup, as long as the broadcasting community is dedicated to continue using this sytem.
Posted at
08:36PM Jun 27, 2008
by beuchelt in General |
TechEd Online Panel on Web Services Interoperability
During TechEd 2008, I participated in a Panel discussion on Web Services Interoperability. Microsoft just put up the tape on their TechNet Library site. They also have a WMV video feed, and a MP3 audio-only feed.
Posted at
08:31PM Jun 27, 2008
by beuchelt in General |
Thursday Jun 26, 2008
Along those lines ...
In my earlier article today I pointed out a rather significant security blunder in Germany, where a number of municipal IT departments failed to secure their systems. This lead to exposure of at least 500,000 personal data records to the internet - so far I have not heard that any affected person was informed about their involuntary expose to identity thieves. In this context it seems a little untimely to publicly announce a new electronic signature program that will start in 2012.Under this program, anyone claiming any benefits from any public source (unemployment, social security, etc.) will be required to use a smart card with a personal key. In addition, employer will have to submit all salary and compensation information to a federal, centralized database that will be fully accessible to all participating government agencies on the federal, state, and local level. Contained in this database are obviously all employer records, but - in all likelihood - also all data records of current or past applications for government benefits. Employees are expected to pay for these new services themselves, with private sector financial institutions or government agencies playing the role of the trust broker.
This program is sold to the public in two ways: on the one hand, it is supposed to save the employers and the government agencies a lot of money by streamlining reporting and decision making processes. On the other hand, in its centralized form it is expected to help limit welfare fraud, which is quite common in Germany. In and by itself, such a database seems harmless enough: it has some tangebile benefits, including significant savings for the private and public sector. However, this effort does not stand by itself. Over the past couple of years, privacy from prying government eyes has been under the most severe attack immaginable: A comprehensive tax ID that is coma
Posted at
06:47PM Jun 26, 2008
by beuchelt in General |
|
|
Subscribe
