Koszt produkcji programowalnego klucza USB z przełącznikiem i hasłami jak Yubikey?

Paweł pisze:

Fajne, ale zamkniete. A musi byc otwarte. Do tego nie moge zmienic
funkcjonalnosci.

Używasz pojęć, które nie dla wszystkich mogą mieć jednakowe znaczenie.
Określ dokładnie co rozumiesz pod pojęciem "otwarte".

Na przykład:
http://code.google.com/p/opencryptotoken/

Czyli jest ogólnie znany schemat urządzenia i dostępny pełny kod
źródłowy firmware.

Fajne, ale zamkniete. A musi byc otwarte. Do tego nie moge zmienic
funkcjonalnosci.

Używasz pojęć, które nie dla wszystkich mogą mieć jednakowe znaczenie.
Określ dokładnie co rozumiesz pod pojęciem "otwarte".

Na przykład:
http://code.google.com/p/opencryptotoken/

Czyli jest ogólnie znany schemat urządzenia i dostępny pełny kod
źródłowy firmware.

Określ dokładnie co rozumiesz pod pojęciem "otwarte".
Na przykład:
http://code.google.com/p/opencryptotoken/

Czyli jest ogólnie znany schemat urządzenia i dostępny pełny kod
źródłowy firmware.

Tak to byl przyklad, ktory podalem. Innym przykladem moze byc telefon neo.

Jeremiasz Kafelski pisze:

Określ dokładnie co rozumiesz pod pojęciem "otwarte".
Na przykład:
http://code.google.com/p/opencryptotoken/

Czyli jest ogólnie znany schemat urządzenia i dostępny pełny kod
źródłowy firmware.

Tak to byl przyklad, ktory podalem. Innym przykladem moze byc telefon
neo.

Neo o ile dobrze pamiętam miał jakąś starą Nokię (8110?) z dodatkową
sprężynką rozsuwającą telefon po naciśnięciu przycisku.
http://www.retrobrick.com/81102.html

Open hardware ani software to on raczej nie był.

Przepraszam, nieprecyzyjnie sie wyrażam

Tak to byl przyklad, ktory podalem. Innym przykladem moze byc telefon
neo.

Neo o ile dobrze pamiętam miał jakąś starą Nokię (8110?)

Przepraszam, nieprecyzyjnie sie wyrażam
http://wiki.openmoko.org/wiki/Neo1973

Tak tajny firmware i tajny klucz prywatny bylby 'jakos' wgrywany do
urzadzenia. Jak ? Nie wiem. Moze przez system plikow, moze przez karte
(czyli czytnik kart dodatkowo), moze jakos inaczej.

Tak tajny firmware i tajny klucz prywatny bylby 'jakos' wgrywany do
urzadzenia. Jak ? Nie wiem. Moze przez system plikow, moze przez karte
(czyli czytnik kart dodatkowo), moze jakos inaczej.

Nie, mam inną wizję. Specjalizowany program na peceta,
napisany i udostępniony użytkownikowi. Ten program, przez
to samo złącze USB by wgrywał część firmware - bo druga część,
odpowiedzialna za odbiór danych z peceta przez USB byłaby
nieruszana. Ta druga część by tylko nasłuchiwała na USB,
czy ktoś (czyli ów specjalizowany program) nie chce czegoś
wgrywać. I nie wtrącała by się w "rzeczywistą" pracę klucza.

Tak tajny firmware i tajny klucz prywatny bylby 'jakos' wgrywany do
urzadzenia. Jak ? Nie wiem. Moze przez system plikow, moze przez karte
(czyli czytnik kart dodatkowo), moze jakos inaczej.
Nie, mam inną wizję. Specjalizowany program na peceta,
napisany i udostępniony użytkownikowi. Ten program, przez
to samo złącze USB by wgrywał część firmware - bo druga część,
odpowiedzialna za odbiór danych z peceta przez USB byłaby
nieruszana. Ta druga część by tylko nasłuchiwała na USB,
czy ktoś (czyli ów specjalizowany program) nie chce czegoś
wgrywać. I nie wtrącała by się w "rzeczywistą" pracę klucza.

To nawet lepsze (dodałbym tylko jednak switch/przełącznik hardwerowy by nie
wgrac bez wyraźnej mojej wiedzy)

Trudno taki klucz by bylo zrobić?

Nie. Albo tak.

To nawet lepsze (dodałbym tylko jednak switch/przełącznik hardwerowy
by nie wgrac bez wyraźnej mojej wiedzy)

Że niby użytkownik bez Twojej wiedzy nie przełączy tego switcha?
Jak chcesz kontrolować zmiany, możesz razem z firmwarem
do wgrania dawać użytkownikowi sumę kontrolną - program
by ją weryfikował i nie wgrał nic bez poprawnej sumy.

Tak tajny firmware i tajny klucz prywatny bylby 'jakos' wgrywany do
urzadzenia. Jak ? Nie wiem. Moze przez system plikow, moze przez karte
(czyli czytnik kart dodatkowo), moze jakos inaczej.
Nie, mam inną wizję. Specjalizowany program na peceta,
napisany i udostępniony użytkownikowi. Ten program, przez
to samo złącze USB by wgrywał część firmware - bo druga część,
odpowiedzialna za odbiór danych z peceta przez USB byłaby
nieruszana. Ta druga część by tylko nasłuchiwała na USB,
czy ktoś (czyli ów specjalizowany program) nie chce czegoś
wgrywać. I nie wtrącała by się w "rzeczywistą" pracę klucza.

To nawet lepsze (dodałbym tylko jednak switch/przełącznik hardwerowy by
nie wgrac bez wyraźnej mojej wiedzy)

Że niby użytkownik bez Twojej wiedzy nie przełączy tego switcha?

Jak chcesz kontrolować zmiany, możesz razem z firmwarem
do wgrania dawać użytkownikowi sumę kontrolną - program
by ją weryfikował i nie wgrał nic bez poprawnej sumy.

Trudno taki klucz by bylo zrobić?

Nie. Albo tak.
Jakie pytanie, taka odpowiedź - ja bym takie programy
(dwa, na peceta i na procesor) napisał w tydzień, w
przerwach obiadowych. Ale nie znam poziomu wiedzy
potencjalnego twórcy.

MKi pisze:

To nawet lepsze (dodałbym tylko jednak switch/przełącznik hardwerowy
by nie wgrac bez wyraźnej mojej wiedzy)

Że niby użytkownik bez Twojej wiedzy nie przełączy tego switcha?
Jak chcesz kontrolować zmiany, możesz razem z firmwarem
do wgrania dawać użytkownikowi sumę kontrolną - program
by ją weryfikował i nie wgrał nic bez poprawnej sumy.

Za proste do obejścia.

Zdecydowanie lepszym rozwiązaniem jest wysyłanie z peceta zaszyfrowanego
apgrejdu (wystarczy do tego choćby AES-128), a klucz deszyfrowania
będzie zaszyty w bootloaderze "klucza" USB. W zależności od potrzeb
można albo generować jeden klucz szyfrowania dla całej serii urządzeń,
albo - ale to już hardcore - indywidualne klucze dla każdego urządzenia,
co wymaga oznaczenia urządzeń np. numerami seryjnymi i generowania
oddzielnego apgrejdu dla każdego egzemplarza.

Raczej ze program bez wiedzy uzytkownika nie przelaczy tego przelacznika.
Uzytkownik to wie co robi a jak nie wie niech nie uzywa.

Jak chcesz kontrolować zmiany, możesz razem z firmwarem
do wgrania dawać użytkownikowi sumę kontrolną - program
by ją weryfikował i nie wgrał nic bez poprawnej sumy.

A jak bedziesz zmienial firmware na nowszy

No cóż to jest odpowiedź

Bootloader by się wgrywało tylko w fabryce.
Reszta, wykonująca właściwe zadanie, wgrywana
byłaby przez bootloader. Gdy ta właściwa "reszta"
dostałaby odpowiednie polecenie z komputera,
przekazywałaby sterowanie do bootlodera
i odchodziła w niebyt.

Dobry pomysł. Należałoby również po każdym włączeniu zasilania/resecie
jeszcze w bootloaderze sprawdzać integralność właściwego programu
(chociażby sumę kontrolną CRC32) i przechodzić w tryb "aktualizacji
firmware" jeżeli coś się pokwasi w pamięci Flash. To przy okazji zapewni
automatyczne wejście do pierwszego programowania podczas produkcji
(wystarczy tylko wgrać na początku goły bootloader).

Dobry pomysł. Należałoby również po każdym włączeniu zasilania/resecie
jeszcze w bootloaderze sprawdzać integralność właściwego programu
(chociażby sumę kontrolną CRC32) i przechodzić w tryb "aktualizacji
firmware" jeżeli coś się pokwasi w pamięci Flash.

Dodam jeszcze, że ratuje też w przypadku przerwy
(np. zanik napięcia) podczas wgrywania firmware.

Jeden z moich projektów dokładnie tak działa,
jak opisałeś. Szpiegostwo przemysłowe?