tail head cat sleep
QR code linking to this page

Man page  — OPIE

명칭

OPIE - 모두에 원 타임 패스워드를

내용

해설

OPIE 는 Bellcore 사의 S/Key 의 제 1 판의 배포물로부터 파생한 패키지입니다. 이 패키지는, 반복 공격 (아래와 같이 참조)으로부터 시스템을 지키는데 도움이 됩니다. OPIE 에서는 이러한 기능을 완수하기 위해, 암호적 해쉬 함수와 챌린지 / 리스폰스 시스템을 이용하고 있습니다. 이 패키지에서는, login(1) (이)나, su(1) 및, ftpd(8) 등과의 치환네로서 OPIE 인증을 짜넣은 프로그램을 제공하고 있습니다. 더욱, OPIE 인증을 이용하기 위해서(때문에)는, 프로그램을 어떻게 고쳐 써야할 것인가 그렇다고 하는 일도 예시합니다. OPIE 는, 합중국 해군 연구소 (the United States Naval Research Laboratory "NRL") 에 두어, 동연구소에서 사용하기 위해 개발되었습니다. OPIE 의 혹부분은, Berkeley Standard Distribution UNIX 및, Bellcore 사의 S/Key 의 Version 1 의 배포물로부터 파생한 것입니다.

통상의 유저의 관점으로부터 하면, OPIE 와는, 유저의 어카운트를 크랙으로부터 지켜 주지만, 귀찮다고 하는 것이 실정이지요. 유저가 처음으로 OPIE 를 사용하고 싶다고 생각했을 때에는, opiepasswd(1) 명령을 이용해, 자기 자신에 관한 항목을 OPIE 데이타베이스에 등록할 필요가 있습니다. 그 후이면, 이 유저는, OPIE 를 짜넣은 어떠한 프로그램에 대해도, 스스로를 인증하기 위해서 OPIE 를 사용할 수 있습니다. 그 밖에 아무것도 클라이언트가 사용되어 있지 않은 경우에는, telnet, rlogin, ftp 에 의해 시스템에 로그인할 때, (모뎀과 같은) 단말 회선에 로그인할 때, 다른 유저에게 어카운트를 바꿀 때, OPIE 를 사용할 수 있습니다. 통상이라면 유저에게 패스워드의 입력을 요구한다라고 하는 장면에서는, 서버는 챌린지를 표시합니다. 이 때, 유저는, 챌린지를 카피해 (또는, 윈도우 시스템과 같은 것 에 의해 카피 페이스트를 실시할 수 없는 경우에는, 손으로 다시 타이프 쳐) OPIE 계산기에 입력해, 더욱 패스워드 (패스 프레이즈)도 OPIE 계산기에 입력하지 않으면 안됩니다. 그리고, 이 유저의 패스워드로서 OPIE 계산기로부터 리스폰스 (을)를 카피하지 않으면 안됩니다 (또는, 손으로 다시 타이프 치지 않으면 안됩니다). 처음은, 이러한 수속은 귀찮게 생각될지도 모릅니다. 그렇지만, 얼마인가 연습을 하면 용이하게 되는 것입니다.

술어

유저명 시스템이 유저를 식별하는 이름입니다. 예를 들면,"jdoe".
비밀의 패스워드
  비밀의 패스워드는 통상 유저가 선정하는 것으로, 시스템에의 액세스권을 얻기 위해 필요합니다. 예를 들면,"SEc1_rt".
챌린지 (누구)
  유저를 인증할 필요가 있는 경우에 시스템에 의해 표시되는, 1조의 정보입니다. OPIE 에서는, 챌린지를 구성하는 편성은, 해시 식별자, 순차 순서 번호, 및 배정 (종)의 3 항목입니다. OPIE 계산기가 적정한 리스폰스를 생성하려면 , 이러한 정보가 필요합니다. 예를 들면,"otp-md5 95 wi14321".
리스폰스 (응답)
  이 챌린지로부터 생성되는 1조의 정보는, 유저를 인증하기 위해 시스템에 의해 사용됩니다. OPIE 에 있어서의 리스폰스는, 6 개의 단어를 1조로 한 것으로, 그 생성은 챌린지와 비밀의 패스워드를 입력해 OPIE 계산기를 이용해 실시합니다. 예를 들면,"PUP SOFT ROSE BIAS FLAG END".
배정 (종)
  이것은, 리스폰스를 계산하기 위해 비밀의 패스워드와 순차 순서 번호와 함께 사용되는 1 개의 정보입니다. 그 목적은 동일한 비밀의 패스워드를, 배정을 변경하는 것만으로 복수의 챌린지 리스폰스 계열에 대해서 사용할 수 있도록(듯이) 하거나 다른 배정을 사용하는 것으로 복수의 머신에 대한 인증에 사용할 수 있도록(듯이) 하는 것입니다.
순차 순서 번호
  열쇠의 반복을 지키기 위해서(때문에) 이용되는 카운터입니다. OPIE 에서는, 시스템이 받는 리스폰스가 성공할 때에 순차 순서 번호는 줄어들어 갑니다. 예를 들면,"95".
해시 식별자
  올바른 리스폰스를 생성하기 위해서 사용하는, 실제의 알고리즘을 식별하기 위한 캐릭터 라인입니다. OPIE 에서는, 유효한 해시 식별자는 2 개 밖에 없습니다. 1 번째의 해시 식별자는 "otp-md4" 로 MD4 의 해쉬 함수를 지정합니다. 그리고, 2 번째의 해시 식별자는 "otp-md5" 로 MD5 의 해쉬 함수를 지정합니다.

반복 공격

독자가 telnet(1) (와)과 같은 네트워크 통신 프로그램을 사용하고 있을 때나, 컴퓨터 시스템에 로그인하기 위해서 모뎀까지도 이용하고 있을 때는, 로그인명과 비밀의 패스워드가 필요합니다. 독자의 로그인명과 비밀의 패스워드를 시스템에 입력할 수 있는 사람이면, 누구라도 독자이라고 식별되어 버립니다. 그것이라고 말하는 것도, 이론적으로는 독자의 패스워드를 알고 있는 것은 독자 밖에 없을 것이기 때문입니다. 유감스럽게, 지금 많은 컴퓨터 통신 미디어에서는 도청이 용이하게 되어 있습니다. 모뎀이나 다양한 네트워크에 의해 통신할 때, 유저의 패스워드는 원격지에의 링크에 대해 통상 안전하다고는 말할 수 없습니다. 유저가 패스워드를 네트워크에 흘릴 때 크래커가 도청하고 있으면(자), 그 크래커는 패스워드의 카피를 손에 넣어 언제라도 좋아하는 때에 독자의 어카운트에 침입할 수가 있습니다. 한 번 안되어, 인터넷상이 많은 사이트에서는 이 대로의 수법으로 침입되어 왔습니다.

공격자로 해 보면 딱 한번으로 좋기 때문에 패스워드를 포착해, 서버에 요구되었을 때에 그 패스워드를 반복만 하면 좋습니다. 비록 패스워드가 encode나 암호화되어 머신간에 통신되고 있어도, 크래커가 사전에 포착하고 있던 통신을 반복하는 것만으로 침입할 수 있는 한, 유저는 위험한 상태에 있습니다. 매우 최근까지, Novell NetWare 는 이것이 약점이었습니다. 크래커에는 진짜 패스워드가 무엇으로 있을까는 몰랐습니다. 그러나, 크래커는 알 필요도 없었습니다 — 왜냐하면, 유저의 어카운트에 침입하기 위해는, 암호화된 패스워드를 포착해 서버에 요구되었을 때에 그 패스워드를 답신하기만 하면 좋았기 때문입니다.

원 타임 패스워드

반복 공격의 문제에 대한 하나의 해결책은, 패스워드를 encode 하는 방법을 계속 바꾼다 일로, 링크를 넘어 다른 시스템에 이송되는 암호를 유일도밖에 사용할 수 없게 하는 것입니다. 만약 이러한 일이 가능하면, 크래커는 몇 번이라도 기분이 내키는까지 반복 공격이 할 수 있겠지요 — 그러나, 얼마 해도 어디의 시스템에도 침입할 수 없을 것입니다. (이)라고 해도 여기서 중요한 (일)것은, encode 한 패스워드를 바탕으로 해 진정한 패스워드나 지금부터 사용하는 encode 한 패스워드를 크래커가 간파해 버리지 않는 같은 방법으로, 정성스럽게 encode를 베푸는 것입니다. 그렇게 하지 않으면, encode 하지 않는 방식이나 고정적인 encode의 방식에 비하면 개선이지만, 역시 어카운트는 침입될 가능성이 있습니다.

S/KEY 알고리즘

이것들총이라고의 문제에 대한 해결책은, 1981 년에 Lamport 가 발명했습니다. 이 기술은, Bellcore 연구소에 있어 Haller, Karn, Walden 등에 의해 실장되었습니다. 그들이 작성한 프리 소프트웨어 패키지는 "S/Key" 라고 명명되어 암호적 체크 섬 (암호적 검사 합계)이라고 하는 알고리즘을 사용하고 있었습니다. 암호적 체크 섬과는 뛰어난 한방향성의 함수로, 함수의 출력을 알 수 있었다고 해도 그런데도 더 공격자는 실질적으로는 입력을 특정할 수 없는 것 같은 것입니다. 그리고, 순회 장황 검사의 체크 섬 (CRC)과 다르고 있는 것은, 암호적 체크 섬에는 결과가 동일한 해시치가 되는 입력이 대부분(거의) 없다고 하는 것입니다.

S/Key 에서는, 변화하는 것은 패스워드가 암호적 해쉬 함수에 대입되는 회수입니다. 우선 패스워드는 암호적 해쉬 함수에 한 번 대입됩니다. 그 출력의 해쉬 함수치는 다시 암호적 해쉬 함수에 대입됩니다. 그 출력치는 더욱 또 암호적 해쉬 함수에 대입됩니다. 그리고, 이 반복은, 패스워드가 암호적 해쉬 함수에 대입되는 회수가 목표의 순차 순서 번호에 이를 때까지 계속됩니다. 이 방식은, 뭐, 예를 들면 순차 순서 번호를 패스워드의 전에 삽입해 암호적 해쉬 함수에 1회만 대입하는 방식보다 꽤 늦지는 됩니다. 그러나, 이 방식에는 유저에게 있어 특히 의의 깊은 이점이 있습니다. 유저가 접속하려고 하고 있는 서버머신은 상술의 고체고체의 계산 전체의 결과가 올바른지 어떤지를 판단하기 위한 어떠한 수단을 가지지 않으면 안됩니다. 서버가 아무런 encode도 없는 채인가, 혹은 통상의 encode만으로 패스워드를 보관하고 있다 경우에는, 크래커는 역시 유저의 패스워드를 입수할 수 있겠지요. 그러나 서버머신이 암호적 해시로 패스워드를 보관 유지하고 있다면, 순차 순서 번호가 변화하고 있는데, 어떻게 매회 리스폰스의 변화 (을)를 계산하면 좋은 것일까요, 또, 도청할 수 없는 것 같은 머신에 유저가 어떻게도 더듬어 붙이지 않는 경우에는 어떻게 해야 할까요? 유저는 링크를 넘어 패스워드를 송신하지 않고 어떻게 패스워드를 변경하면(자) 좋은 것일까요?

명심해 두어야 한다 Lamport 가 고안 한 교묘한 해결책이란, 순차 순서 번호는 항상 1 씩 감소시키는 것, 다음에 S/Key 시스템에서는 단지 순차 순서 번호 N 의 리스폰스를 암호적 해쉬 함수에 대입해 계산하는 것만으로 순차 순서 번호 N+1 의 리스폰스를 이득개와가 성과 일, 다만, 역방향의 계산은 할 수 없다고 하는 것입니다. 그런데, 임의의 지정되었을 때 각에 마지막에 유효했다 시스템이 가지고 있는 리스폰스의 순차 순서 번호를 N+1 로 해, 유저가 시스템으로 지정한 리스폰스의 순차 순서 번호를 N 로 합니다. N 차례의 리스폰스를 생성하는 패스워드가 N+1 차례의 리스폰스를 생성하는 패스워드와 같은 경우에는, N 차례의 리스폰스를 암호적 해쉬 함수에 다시 한번 대입해 총계 N+1 번째의 대입을 실시해, N+1 차례의 리스폰스와 같은 것을 얻을 수 있습니다. 이것들 2 개의 리스폰스를 비교해 같은 경우에는, N 로부터 1 을 빼 지금 증명한지 얼마 안된 N 차례의 키를 N+1 차례의 새로운 키로 할 수가 있습니다. 유저는 이 새로운 키를 보존해 다음번에 키를 증명해야 할 때에 사용할 수 있습니다. 이것은 다음 일도 의미하고 있습니다. 즉, 유저가 패스워드를 변경해야 하는데 머신에 액세스 하는 안전한 방법이 없는 경우에는, 유저의 패스워드를 인증하기 위해 시스템에 정말로 필요하게 되는 것은, 유저가 개시하고 싶은 순차 순서 번호보다 1 개(살)만 큰 순차 순서 번호 에 대한 유효한 리스폰스이다고 하는 것입니다.

좋은 대책으로서만의 이유로, 실제로 리스폰스를 생성하거나 인증하거나 할 때에, 이 모든 인증의 어느 쪽의 측에 두어도 패스워드에 가세해 배정을 사용할 수 있습니다. 이것에 의해, 만일때에 대비해 상황을 복잡하게 혼합하고 돌려주는 것에 다소는 도움이 됩니다. 그렇지 않으면, 윤택한 시간과 디스크 스페이스를 자유롭게 할 수 있는 크래커는, 수많은 흔히 있던 패스워드에 대응하는 리스폰스를 모두 생성해 시스템을 패배시킬 수가 있겠지요.

이상 기술했던 것은 결코 S/Key 알고리즘이 어떻게 기능하는가 하는 것이나 몇개의보다 세부의 항목 에 대한 최선의 설명이 아닙니다. 그러니까, 유저는 이 문제에 대해 현재 공개되고 있는 몇개의 논문을 참조해야 하는 것이지요. 이상은 덮개아래에서 무엇을 하고 있을까라고 하는 것에 대하여의 그저 임시적인 입문입니다.

OPIE 의 원가요소

OPIE 배포물은 3 개의 표준적인 클라이언트 프로그램에 짜넣어지고 있습니다. 즉, login(1) , su(1) , 및 ftpd(8) 입니다.

OPIE 배포물에는 또, OPIE 시스템에 고유한 3 개의 프로그램이 있습니다. 즉, opiepasswd(1) (은)는 유저가 패스워드를 설정하거나 변경하거나 하는데 사용합니다. opieinfo(1) (은)는 유저가 현재의 순차 순서 번호나 배정을 조사하기 위해서(때문에) 사용합니다. 그리고, opiekey(1) (은)는 OPIE 열쇠 계산기입니다.

OPIE 의 유저 프로그램에의 짜넣어

OPIE 배포물에 클라이언트로서 포함되어 있다 프로그램 이외의 유저 프로그램에 OPIE 인증을 짜넣는 것은 별로 곤란한 일이 아닙니다. 우선 제 1 에, 프로그램의 어디엔가 <stdio.h> 가 include 되고 있는 것을 확인하지 않으면 안됩니다. 다음에,<stdio.h> 나 다른 include 선언의 후방에서 한편, 변수 선언의 전방으로, <opie.h> (을)를 include 하지 않으면 안됩니다. "struct opie" 형의 변수를 독자의 프로그램에 가세하지 않으면 안됩니다. 독자가 유저의 패스워드를 격납하는데 이용하는 버퍼가 OPIE_RESPONSE_MAX+1 개의 캐릭터를 충분히 보관 유지 가능한 한 큰 것을 확인할 필요가 있습니다. 그리고, 챌린지 캐릭터 라인을 격납하는 버퍼도 OPIE_CHALLENGE_MAX+1 개의 캐릭터를 충분히 보관 유지 가능한 한 큰 것을 확인하지 않으면 안됩니다.

독자가 챌린지 캐릭터 라인을 표시해 유저의 이름을 알려고 할 때는, opiechallenge 함수를 소환이라고 주세요. 더욱, 받은 리스폰스를 조합하기 위해는 opieverify 함수를 소환이라고 주세요. 예를 들면,

        #include <stdio.h>

                .

                .

        #include <opie.h>

                .

                .

        char *user_name;

        /* 항상 말미의 눌 캐릭터를 잊지 않는 것! */

        char password[OPIE_RESPONSE_MAX+1];

                .

                .

        struct opie opiedata;

        char opieprompt[OPIE_CHALLENGE_MAX+1];

                .

                .

        opiechallenge(&opiedata, user_name, opieprompt);

                .

                .

        if (opieverify(&opiedata, password)) {

                printf("Login incorrect");

단말의 보안와 OPIE

유저가 OPIE 를 사용하려면 , 누군가가 도청을 해 패스워드를 포착할 수 있는 것 같은 안전하지 않은 경로를 통해서 패스워드를 송신하지 않게 주의하지 않으면 안됩니다. 회선을 도청해 패스워드를 취득하려고 하는 사람으로부터, 유저를 OPIE 는 보호 가능합니다. 그러나, 이것은 실은 한정되었을 경우이며, 유저가 반드시 패스워드 그 자체를 통신회선에 송신하지 않게 행동하는 때만입니다. 간신인 (일)것은, OPIE 계산기를 동작시키는 머신은, 항상 유저가 현실에 수중에서 사용하고 있는 머신이 아니면 안된다고 하는 것으로 — 결코 네트워크나 다이얼 업 회선의 저쪽 편의 머신이어서는 안됩니다.

X 윈도우 시스템에 관해서는 주의가 필요합니다. 그 이유는 X 윈도우 시스템을 사용하면 사정이 크게 바뀌기 때문입니다. 예를 들면, 유저가 xterm (또는 기호의 동등 프로그램) (을)를 어딘가 다른 머신상에서 동작시키고 그것을 유저의 머신에 표시시키는 경우에는, OPIE 계산기를 그 윈도우로 동작시켜서는 안됩니다. 비밀의 패스워드를 키인 했을 경우에는, 패스워드는 역시 네트워크상을 xterm 가 동작하고 있는 머신까지 전송됩니다. 네트워크 넘어로 밖에 OPIE 계산기를 동작 시킬 수 없는 X 단말과 같은 머신 (을)를 사용하고 있는 사람들은 특별히 위험에 처해지고 있습니다. 그렇다고 하는 것도, 실은 이러한 사람들에게는 그 밖에 선택의 여지가 없기 때문입니다. 또, 다른 어떠한 윈도우 시스템 (예를 들면, NeWS)과 같이 X 윈도우 시스템을 사용하고 있는 경우, 비유하고 OPIE 계산기를 로컬 머신상에서 동작시키고 있었다고 해도 독자의 키 조작을 읽어 패스워드를 포착하는 것은 때때로 가능합니다. X 서버를 지키기 위해서 항상 독자의 시스템으로 이용 가능한 최고의 보안 수단을 사용해야 합니다. 비록 그것이, XDM-AUTHORIZATION-1 나 XDM-MAGIC-COOKIE-1, 혹은 호스트 액세스 컨트롤이었다고 해도. *결코*어느 머신에서도 독자의 서버에 접속할 수 있게 해서는 안됩니다. 왜냐하면, 이렇게 해 버리면(자), 독자가 깨닫지 못하는 동안에, 독자의 어떠한 윈도우나 키 조작을 읽어내는 것을, 임의의 머신에 허락하게 되기 때문입니다.

관련 항목

ftpd(8) login(1), opie(4), opiekeys(5), opieaccess(5), opiekey(1), opieinfo(1), opiepasswd(1),

Lamport, L. "Password Authentication with Insecure Communication (안전하지 않은 통신에 있어서의 패스워드의 인증)", Communications of the ACM 24.11 (November 1981), pp. 770-772.

Haller, N. "The S/KEY One-Time Password System (S/Key 원 타임 패스워드 시스템)", Proceedings of the ISOC Symposium on Network and Distributed System Security, February 1994, San Diego, CA..

Haller, N. and Atkinson, R, "On Internet Authentication (인터넷의 인증에 관해서)", RFC-1704, DDN Network Information Center, October 1994.

Rivest, R. "The MD5 Message Digest Algorithm (MD5 에 의한 메세지 다이제스트의 알고리즘)", RFC-1321, DDN Network Information Center, April 1992.

Rivest, R. "The MD4 Message Digest Algorithm (MD4 에 의한 메세지 다이제스트의 알고리즘)", RFC-1320, DDN Network Information Center, April 1992.

저자

Bellcore 사의 S/Key 는 Bellcore 사의 Phil Karn,
Neil M. Haller, John S. Walden 하지만 썼습니다. OPIE 는 NRL 에 대해 Randall Atkinson, Dan McDonald, Craig Metz 하지만 작성했습니다.

"S/Key" 는 벨 통신 연구소 (Bell Communications Research [Bellcore])의 소유하는 등록상표입니다. "UNIX" 는 X/Open 의 소유하는 등록상표입니다.

연락처

OPIE 는 Bellcore 사의 「 S/Key 유져스」메일링리스트 에 두어 논의되고 있습니다. 이 메일링리스트에 참가하려면 , 신청의 전자 메일을 다음의 주소에 보내 주세요:

skey-users-request@thumper.bellcore.com


January 10, 1995 OPIE (4)

tail head cat sleep
QR code linking to this page


Ben Bullock이 유닉스 매뉴얼 페이지에서 서비스에 대한 의견을 주시기 바랍니다. Privacy policy.

A child of 5 could understand this! Fetch me a child of 5.