<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Yubico öppnar upp sin teknologi och kod</title>
	<atom:link href="http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/feed/" rel="self" type="application/rss+xml" />
	<link>http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/</link>
	<description>Kryptografi och IT-säkerhet på svenska</description>
	<pubDate>Fri, 05 Dec 2008 12:25:22 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Nixon</title>
		<link>http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/#comment-34708</link>
		<dc:creator>Nixon</dc:creator>
		<pubDate>Fri, 27 Jun 2008 11:42:45 +0000</pubDate>
		<guid isPermaLink="false">http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/#comment-34708</guid>
		<description>Yubikey är jättesöt, och verkar lösa många av användbarhetsproblemen med de vanliga dosorna. Men det som gör att vi inte tittar vidare på Yubikey för närvarande är att man lägger alla ägg i samma korg. Blir autenticeringsservern knäckt ryker hela din autenticeringsinfrastruktur. Det är lika skoj som när en Kerberos-KDC blir knäckt, men med extrabonusen att det inte bara är lösenord som måste bytas, utan fysisk hårdvara.</description>
		<content:encoded><![CDATA[<p>Yubikey är jättesöt, och verkar lösa många av användbarhetsproblemen med de vanliga dosorna. Men det som gör att vi inte tittar vidare på Yubikey för närvarande är att man lägger alla ägg i samma korg. Blir autenticeringsservern knäckt ryker hela din autenticeringsinfrastruktur. Det är lika skoj som när en Kerberos-KDC blir knäckt, men med extrabonusen att det inte bara är lösenord som måste bytas, utan fysisk hårdvara.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joachim</title>
		<link>http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/#comment-34190</link>
		<dc:creator>Joachim</dc:creator>
		<pubDate>Sun, 15 Jun 2008 06:55:05 +0000</pubDate>
		<guid isPermaLink="false">http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/#comment-34190</guid>
		<description>Aloha!

Min uppfattning är att med Yubikey går det att lyfta nivån på den enklaste typ av säkerhet - lösenord eller PIN-kod till något som är mycket svårare att gissa.

Och tricket man gör detta genom är att omvandla säkerheten från något man vet till något man har.

Yubikey är inte Fort Knox, men det är otroligt mycket bättre än att Sigge använder lösenordet "sigge".</description>
		<content:encoded><![CDATA[<p>Aloha!</p>
<p>Min uppfattning är att med Yubikey går det att lyfta nivån på den enklaste typ av säkerhet - lösenord eller PIN-kod till något som är mycket svårare att gissa.</p>
<p>Och tricket man gör detta genom är att omvandla säkerheten från något man vet till något man har.</p>
<p>Yubikey är inte Fort Knox, men det är otroligt mycket bättre än att Sigge använder lösenordet &#8220;sigge&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon</title>
		<link>http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/#comment-33928</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Mon, 09 Jun 2008 15:35:49 +0000</pubDate>
		<guid isPermaLink="false">http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/#comment-33928</guid>
		<description>f0bar,

Tanken är inte att AES-nyckeln ska cirkulera runt, det ställer för stora krav på att man litar på alla inblandade parter eftersom, som du påpekar, alla parter då kan fejka inloggningar hos varandra.

Min analys var skriven långt innan det fanns någon server, så det är inte så konstigt att den inte täcker detta. :)

Vår tanke idag är att den som köper nyckel bestämmer ett ställe där AES nyckeln ska lagras, och låter det stället köra vårt web-service-API för att besvara förfrågningar om valideringar.  De tjänster som ska validera nycklarna får då prata med servern, och måste då lita på servern.

Dock är vår affärsmodell att sälja nycklarna, så om du vill använda dem i en annan modell så går det bra.

Att använda public-key är något vi övervägt, men det för med sig flera problem, varav dessa är de största:

1) Processorn måste vara betydligt kraftigare (= dyrare) eftersom den måste implementera bignum (RSA) och hashning.

2) En RSA-signature är _betydligt_ längre än de 44 tecken yubikey'n matar ut idag.  Enkelt överslag ger det 512 modhex-tecken för en 2048-bits RSA-nyckel.  Detta tar för lång tid att föra över till datorn.

3) Hantering av revokering av nycklar kräver en online-tjänst eller besvärlig CRL-hantering.  Så man behöver ändå en online-server, vilket kan betraktas som en nackdel med dagens lösning.

Andra får gärna titta närmare på vår modell och göra sin egen analys.  

Mvh,
Simon (@yubico.com)</description>
		<content:encoded><![CDATA[<p>f0bar,</p>
<p>Tanken är inte att AES-nyckeln ska cirkulera runt, det ställer för stora krav på att man litar på alla inblandade parter eftersom, som du påpekar, alla parter då kan fejka inloggningar hos varandra.</p>
<p>Min analys var skriven långt innan det fanns någon server, så det är inte så konstigt att den inte täcker detta. <img src='http://strombergson.com/kryptoblog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>Vår tanke idag är att den som köper nyckel bestämmer ett ställe där AES nyckeln ska lagras, och låter det stället köra vårt web-service-API för att besvara förfrågningar om valideringar.  De tjänster som ska validera nycklarna får då prata med servern, och måste då lita på servern.</p>
<p>Dock är vår affärsmodell att sälja nycklarna, så om du vill använda dem i en annan modell så går det bra.</p>
<p>Att använda public-key är något vi övervägt, men det för med sig flera problem, varav dessa är de största:</p>
<p>1) Processorn måste vara betydligt kraftigare (= dyrare) eftersom den måste implementera bignum (RSA) och hashning.</p>
<p>2) En RSA-signature är _betydligt_ längre än de 44 tecken yubikey&#8217;n matar ut idag.  Enkelt överslag ger det 512 modhex-tecken för en 2048-bits RSA-nyckel.  Detta tar för lång tid att föra över till datorn.</p>
<p>3) Hantering av revokering av nycklar kräver en online-tjänst eller besvärlig CRL-hantering.  Så man behöver ändå en online-server, vilket kan betraktas som en nackdel med dagens lösning.</p>
<p>Andra får gärna titta närmare på vår modell och göra sin egen analys.  </p>
<p>Mvh,<br />
Simon (@yubico.com)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: f0bar</title>
		<link>http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/#comment-33192</link>
		<dc:creator>f0bar</dc:creator>
		<pubDate>Sat, 17 May 2008 12:04:35 +0000</pubDate>
		<guid isPermaLink="false">http://strombergson.com/kryptoblog/2008/05/17/yubico-oppnar-upp-sin-teknologi-och-kod/#comment-33192</guid>
		<description>Om jag förstår det hela rätt betyder det att man måste ge sin AES nyckel till alla som ska kunna authentisera en. Detta betyder att man måste lita på / ha trust till den man vill authentisera sig hos.

Jag tycker säkerhets analysen som Simon gjort säger väldigt lite, eller inget alls om hur själva authentiseringen av användaren går till och att servern som ska authentisera sig faktiskt måste känna till den nyckeln.

Ett alternativ för att få det "bättre" antar jag kan vara att köra sin egen openID server och alltid authentisera sig mot den. Jag hade dock klart föredragigt att man hade haft ett public/private key system och därmed hade det endast varit en enda usbsticka som kunde skapa giltiga authentiseringar.

Det känns som säkerheten faller tillbaka på lösenordet man valt iallafall och att själva enheten blir lite snakeoil eftersom både Yubico och alla servrar man vill authentisera sig mot kan fejka authentiseringar.

Vore klart intressant att se en tredje parts analys av systemet.</description>
		<content:encoded><![CDATA[<p>Om jag förstår det hela rätt betyder det att man måste ge sin AES nyckel till alla som ska kunna authentisera en. Detta betyder att man måste lita på / ha trust till den man vill authentisera sig hos.</p>
<p>Jag tycker säkerhets analysen som Simon gjort säger väldigt lite, eller inget alls om hur själva authentiseringen av användaren går till och att servern som ska authentisera sig faktiskt måste känna till den nyckeln.</p>
<p>Ett alternativ för att få det &#8220;bättre&#8221; antar jag kan vara att köra sin egen openID server och alltid authentisera sig mot den. Jag hade dock klart föredragigt att man hade haft ett public/private key system och därmed hade det endast varit en enda usbsticka som kunde skapa giltiga authentiseringar.</p>
<p>Det känns som säkerheten faller tillbaka på lösenordet man valt iallafall och att själva enheten blir lite snakeoil eftersom både Yubico och alla servrar man vill authentisera sig mot kan fejka authentiseringar.</p>
<p>Vore klart intressant att se en tredje parts analys av systemet.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
