Cześć,

Może Wy mnie naprowadzicie.

Potrzebuję w określonej sytuacji wygenerować użytkownikowi 8-cyfrowy kod
(ostatecznie cyfr może być więcej, ale raczej nie więcej niż 10), który
zostanie zweryfikowany przez urządzenie i zostanie wykonana określona
akcja. Ten kod musi być przeznaczony tylko dla tego urządzenia i ważny
tylko przez określony czas (założyłem, że dwa dni wystarczą; użytkownik
nie ma możliwości manipulacji datą na urządzeniu).

Wymyśliłem, żeby podczas generacji złożyć do kupy nr seryjny urządzenia,
aktualną datę, dorzucić do tego sekretny klucz, zrobić skrót SHA-256,
wziąć pierwsze cztery bajty, zamienić je do postaci dziesiętnej i
ewentualnie obciąć lub dopełnić zerami. Urządzenie podczas weryfikacji
zrobiłoby to samo (a jak weryfikacja się nie uda, to dla daty dnia
poprzedniego).

Problem jest tylko taki, że sekretny klucz musi być również na urządzeniu,
czyli potencjalnie do wyciągnięcia z urządzenia lub np. z plików update'u
(zaszycie go gdzieś mi się nie podoba, bo on nadal tam będzie). Chciałbym,
żeby go nie było.

Pierwsze, o czym pomyślałem, to użycie kryptografii asymetrycznej i
wrzucanie na urządzenia kluczy publicznych, a do generacji używanie klucza
prywatnego. Wtedy podpisywałbym wspomniane dane tym kluczem (wtedy już bez
sekretnego klucza symetrycznego), a urządzenie mogłoby sobie ten podpis
zweryfikować.

Tylko czy jest jakiś sposób, żeby przesłać sygnaturę w postaci niecałych
czterech bajtów (8 cyfr 0-9), ewentualnie całych (jak zwiększę liczbę cyfr
do 10)? Przecież urządzenie jej nie wygeneruje i nie obetnie sobie, żeby
ręcznie porównać zgodność, tak jak w przypadku wspomnianego wcześniej
skrótu.

Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może
zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?

To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to
zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie
ze sztuką.

Pozdr.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

On Tuesday, March 13, 2018 at 5:11:54 PM UTC+1, Adam Wysocki wrote:
> Cześć,
>
> Może Wy mnie naprowadzicie.
>
> Potrzebuję w określonej sytuacji wygenerować użytkownikowi 8-cyfrowy kod
> (ostatecznie cyfr może być więcej, ale raczej nie więcej niż 10), który
> zostanie zweryfikowany przez urządzenie i zostanie wykonana określona
> akcja. Ten kod musi być przeznaczony tylko dla tego urządzenia i ważny
> tylko przez określony czas (założyłem, że dwa dni wystarczą; użytkownik
> nie ma możliwości manipulacji datą na urządzeniu).
>
> Wymyśliłem, żeby podczas generacji złożyć do kupy nr seryjny urządzenia,
> aktualną datę, dorzucić do tego sekretny klucz, zrobić skrót SHA-256,
> wziąć pierwsze cztery bajty, zamienić je do postaci dziesiętnej i
> ewentualnie obciąć lub dopełnić zerami. Urządzenie podczas weryfikacji
> zrobiłoby to samo (a jak weryfikacja się nie uda, to dla daty dnia
> poprzedniego).
>
> Problem jest tylko taki, że sekretny klucz musi być również na urządzeniu,
> czyli potencjalnie do wyciągnięcia z urządzenia lub np. z plików update'u
> (zaszycie go gdzieś mi się nie podoba, bo on nadal tam będzie). Chciałbym,
> żeby go nie było.
>
> Pierwsze, o czym pomyślałem, to użycie kryptografii asymetrycznej i
> wrzucanie na urządzenia kluczy publicznych, a do generacji używanie klucza
> prywatnego. Wtedy podpisywałbym wspomniane dane tym kluczem (wtedy już bez
> sekretnego klucza symetrycznego), a urządzenie mogłoby sobie ten podpis
> zweryfikować.
>
> Tylko czy jest jakiś sposób, żeby przesłać sygnaturę w postaci niecałych
> czterech bajtów (8 cyfr 0-9), ewentualnie całych (jak zwiększę liczbę cyfr
> do 10)? Przecież urządzenie jej nie wygeneruje i nie obetnie sobie, żeby
> ręcznie porównać zgodność, tak jak w przypadku wspomnianego wcześniej
> skrótu.
>
> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może
> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
>
> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to
> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie
> ze sztuką.

Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z urządzenia,
to w urządzeniu powinny być przechowywane tylko funkcje skrótu - tak jest
np. w logowaniu do linuxa. Dlaczego nie możesz zastosować takiego rozwiązania?

Pozdrawiam

do góry

On Tue, 13 Mar 2018 11:39:22 -0700 (PDT), M.M. wrote:

>> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może
>> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
>>
>> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to
>> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie
>> ze sztuką.
>
> Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z urządzenia,
> to w urządzeniu powinny być przechowywane tylko funkcje skrótu - tak jest
> np. w logowaniu do linuxa. Dlaczego nie możesz zastosować takiego rozwiązania?

Bo ta informacja ma być składnikiem danych do funkcji skrótu.

--
pozdrawiam
Roman Tyczka

do góry

On Tuesday, March 13, 2018 at 7:50:28 PM UTC+1, Roman Tyczka wrote:
> On Tue, 13 Mar 2018 11:39:22 -0700 (PDT), M.M. wrote:
>
> >> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może
> >> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
> >>
> >> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to
> >> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie
> >> ze sztuką.
> >
> > Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z urządzenia,
> > to w urządzeniu powinny być przechowywane tylko funkcje skrótu - tak jest
> > np. w logowaniu do linuxa. Dlaczego nie możesz zastosować takiego rozwiązania?
>
> Bo ta informacja ma być składnikiem danych do funkcji skrótu.

Generalnie pytam, dlaczego nie można zastosować standardowych rozwiązań?

Do szyfrowania haseł w trakcie autoryzacji używamy - funkcji skrótu. Do
transmisji - protokołu szyfrowanego. Dane przechowujemy - zaszyfrowane.

Pozdrawiam

do góry

On Tue, 13 Mar 2018 12:09:35 -0700 (PDT), M.M. wrote:

> On Tuesday, March 13, 2018 at 7:50:28 PM UTC+1, Roman Tyczka wrote:
>> On Tue, 13 Mar 2018 11:39:22 -0700 (PDT), M.M. wrote:
>>
>>>> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może
>>>> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
>>>>
>>>> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to
>>>> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie
>>>> ze sztuką.
>>>
>>> Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z urządzenia,
>>> to w urządzeniu powinny być przechowywane tylko funkcje skrótu - tak jest
>>> np. w logowaniu do linuxa. Dlaczego nie możesz zastosować takiego rozwiązania?
>>
>> Bo ta informacja ma być składnikiem danych do funkcji skrótu.
>
> Generalnie pytam, dlaczego nie można zastosować standardowych rozwiązań?
>
> Do szyfrowania haseł w trakcie autoryzacji używamy - funkcji skrótu. Do
> transmisji - protokołu szyfrowanego. Dane przechowujemy - zaszyfrowane.

Nie wczytałeś się w opis problemu.
Adam ma dwa, niezależne "komputery". Nie ma między nimi łączności. I teraz
pierwszy musi w tych okolicznościach wygenerować jakiś klucz, a drugi musi
umieć go zweryfikować. Do tego dochodzi czas życia klucza.
Wymyślił, że na pierwszym "komputerze" doda do kupy datę, identyfikator
drugiego "kompa" i sól (sekretny klucz), potem obliczy z tego hasza, a na
drugim w czasie weryfikacji zrobi to samo i porówna wynik.

--
pozdrawiam
Roman Tyczka

do góry

M.M. <m...@g...com> wrote:

> Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z
> urządzenia, to w urządzeniu powinny być przechowywane tylko funkcje
> skrótu - tak jest np. w logowaniu do linuxa. Dlaczego nie możesz
> zastosować takiego rozwiązania?

Bo te dane nie są stałe. Chcę żeby były generowane w oparciu o datę i SN,
bo nie chcę, żeby ten klucz działał w nieskończoność i na każdym
urządzeniu.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

On Tue, 13 Mar 2018 16:11:51 +0000 (UTC), Adam Wysocki wrote:

Ja tylko tego momentu nie rozumiem:

> Tylko czy jest jakiś sposób, żeby przesłać sygnaturę w postaci niecałych
> czterech bajtów (8 cyfr 0-9), ewentualnie całych (jak zwiększę liczbę cyfr
> do 10)? Przecież urządzenie jej nie wygeneruje i nie obetnie sobie, żeby
> ręcznie porównać zgodność, tak jak w przypadku wspomnianego wcześniej
> skrótu.

O jakiej sygnaturze mowa? Oraz dlaczego "urządzenie jej nie wygeneruje"
skoro może obliczać hasze i robić inne rzeczy?

--
pozdrawiam
Roman Tyczka

do góry

On Wednesday, March 14, 2018 at 9:40:47 AM UTC+1, Adam Wysocki wrote:
> M.M. <m...@g...com> wrote:
>
> > Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z
> > urządzenia, to w urządzeniu powinny być przechowywane tylko funkcje
> > skrótu - tak jest np. w logowaniu do linuxa. Dlaczego nie możesz
> > zastosować takiego rozwiązania?
>
> Bo te dane nie są stałe.
Ja już tego nie rozumiem. Co ma stałość lub nie stałość danych wspólnego z
szyfrowanym protokołem którym są przesyłane?

> Chcę żeby były generowane w oparciu o datę i SN,
Ja myślałem, że chcesz bezpieczeństwa.

> bo nie chcę, żeby ten klucz działał w nieskończoność i na
> każdym urządzeniu.
W ramach podstawowego standardu bezpieczeństwa jest zmiana
hasła i inne hasło do każdego urządzenia.

Pozdrawiam

do góry

On Tuesday, March 13, 2018 at 8:22:29 PM UTC+1, Roman Tyczka wrote:
> On Tue, 13 Mar 2018 12:09:35 -0700 (PDT), M.M. wrote:
>
> > On Tuesday, March 13, 2018 at 7:50:28 PM UTC+1, Roman Tyczka wrote:
> >> On Tue, 13 Mar 2018 11:39:22 -0700 (PDT), M.M. wrote:
> >>
> >>>> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może
> >>>> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
> >>>>
> >>>> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to
> >>>> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie
> >>>> ze sztuką.
> >>>
> >>> Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z urządzenia,
> >>> to w urządzeniu powinny być przechowywane tylko funkcje skrótu - tak jest
> >>> np. w logowaniu do linuxa. Dlaczego nie możesz zastosować takiego rozwiązania?
> >>
> >> Bo ta informacja ma być składnikiem danych do funkcji skrótu.
> >
> > Generalnie pytam, dlaczego nie można zastosować standardowych rozwiązań?
> >
> > Do szyfrowania haseł w trakcie autoryzacji używamy - funkcji skrótu. Do
> > transmisji - protokołu szyfrowanego. Dane przechowujemy - zaszyfrowane.
>
> Nie wczytałeś się w opis problemu.
> Adam ma dwa, niezależne "komputery". Nie ma między nimi łączności.
Tego opisu nie da się zrozumieć. Jak ma zweryfikować, jeśli nie ma
łączności? Jeśli przenosisz na dyskietce to przecież to też jest
bardzo typowy rodzaj łączności/transmisji - i jak najbardziej
standardowego szyfrowania można użyć do przenoszenia danych na
dyskietce.


> I teraz
> pierwszy musi w tych okolicznościach wygenerować jakiś klucz, a drugi musi
> umieć go zweryfikować.
Proszę bardzo, na pierwszym komputerze program wygenerowało liczbę jeden,
na drugim sprawdza czy to faktycznie jest jedynka. Oczywiście transmisja
musi być aby to zweryfikować, a jak ktoś sobie życzy, to i może być
transmisja szyfrowana.


> Do tego dochodzi czas życia klucza.
> Wymyślił, że na pierwszym "komputerze" doda do kupy datę, identyfikator
> drugiego "kompa" i sól (sekretny klucz), potem obliczy z tego hasza, a na
> drugim w czasie weryfikacji zrobi to samo i porówna wynik.
No ale po co, czy pytając grzecznie, w jakim celu?


Pozdrawiam.

do góry

On Wed, 14 Mar 2018 04:12:01 -0700 (PDT), M.M. wrote:

>>> Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z
>>> urządzenia, to w urządzeniu powinny być przechowywane tylko funkcje
>>> skrótu - tak jest np. w logowaniu do linuxa. Dlaczego nie możesz
>>> zastosować takiego rozwiązania?
>>
>> Bo te dane nie są stałe.
> Ja już tego nie rozumiem. Co ma stałość lub nie stałość danych wspólnego z
> szyfrowanym protokołem którym są przesyłane?
>
>> Chcę żeby były generowane w oparciu o datę i SN,
> Ja myślałem, że chcesz bezpieczeństwa.
>
>> bo nie chcę, żeby ten klucz działał w nieskończoność i na
>> każdym urządzeniu.
> W ramach podstawowego standardu bezpieczeństwa jest zmiana
> hasła i inne hasło do każdego urządzenia.

I co dwa dni zmieniać i dystrybuować nowe hasło?

Nie wiem czemu robię to za Adama, ale jeszcze raz:

Wyobraź sobie parking, przed wjazdem szlaban na kod. Jutro zaczynamy
konferencję dwudniową, na parkingu zaroi się od gości z całego kraju. Ale
żeby mogli zaparkować muszą wpisać na czytniku 8 znakowy kod. Trzeba im
więc go wygenerować i wysłać dzisiaj mailem. Ale kod nie może być stały, bo
za 5 dni jest inny zjazd i inna grupa przyjedzie, im też trzeba będzie dać
kody ważne dwa dni.
Zatem potrzebny jest sposob by zarówno generowanie kodu do maila, jak i
dekodowanie w czytniku przy szlabanie było zgodne i wiedziało, że ten kod
jest ważny dziś i wczoraj.

--
pozdrawiam
Roman Tyczka

do góry