eGospodarka.pl

eGospodarka.plGrupypl.comp.programming › PKI a weryfikacja krótkiego podpisu (3 bajty)
Ilość wypowiedzi w tym wątku: 18

  • 1. Data: 2018-03-13 17:11:51
    Temat: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: g...@s...invalid (Adam Wysocki)

    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/ ]


  • 2. Data: 2018-03-13 19:39:22
    Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: "M.M." <m...@g...com>

    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


  • 3. Data: 2018-03-13 19:50:24
    Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: Roman Tyczka <n...@b...no>

    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


  • 4. Data: 2018-03-13 20:09:35
    Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: "M.M." <m...@g...com>

    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


  • 5. Data: 2018-03-13 20:22:25
    Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: Roman Tyczka <n...@b...no>

    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


  • 6. Data: 2018-03-14 09:40:44
    Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: g...@s...invalid (Adam Wysocki)

    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/ ]


  • 7. Data: 2018-03-14 10:52:45
    Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: Roman Tyczka <n...@b...no>

    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


  • 8. Data: 2018-03-14 12:12:01
    Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: "M.M." <m...@g...com>

    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



  • 9. Data: 2018-03-14 12:19:29
    Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: "M.M." <m...@g...com>

    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.


  • 10. Data: 2018-03-14 12:29:54
    Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Od: Roman Tyczka <n...@b...no>

    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

strony : [ 1 ] . 2



Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo:

Ok, rozumiem Strona wykorzystuje pliki cookies w celu prawidłowego jej działania oraz korzystania z narzędzi analitycznych, reklamowych, marketingowych i społecznościowych. Szczegóły znajdują się w Polityce Prywatności. Dalsze korzystanie ze strony oznacza, że zgadzasz się na ich użycie. Jeśli nie chcesz, aby pliki cookies były zapisywane w pamięci Twojego urządzenia, możesz to zmienić za pomocą ustawień przeglądarki.