원본 : http://www.hurryon.org/index.php/hurryon/2006-03#31


Cryptography traditionally used the names Alice and Bob to refer to two parties who want to communicate securely over an insecure channel. Eve is the traditional name of someone who wishes to intercept and read their communications. I have come across a good link on the Internet about the traditional names in Cryptography scope. A few important names are below:
Alice and Bob. Generally Alice wants to send a message to Bob. These names were invented by Ron Rivest for the 1978 Communications of the ACM article presenting the RSA cryptosystem. (The 1977 technical report on RSA did not use these names.) Rivest denies that these names have any relation with the 1969 movie Bob & Carol & Ted & Alice as occasionally suggested by others.

Carol, as a third participant in communications. Thereafter, we often have Dave, a fourth participant, and so on alphabetically.

Eve, an eavesdropper, is usually a passive attacker. While she can listen in on messages between Alice and Bob, she cannot modify them. In quantum cryptography, Eve may also represent the environment.

Isaac, an Internet Service Provider (ISP).

Ivan, an issuer (as in financial cryptography).

Justin, from the justice system.

Mallory, a malicious attacker; unlike Eve, Mallory can modify messages, substitute her own messages, replay old messages, and so on. The problem of securing a system against Mallory is much greater than against Eve. The names Marvin and Mallet can also be used for this role.

Matilda, a merchant (as in ecommerce or financial cryptography).

Oscar, an opponent, is usually taken as equivalent to Mallory.

Pat, see Peggy.

Peggy, a prover, and Victor, a verifier, often must interact in some way to show that the intended transaction has actually taken place. They are often found in zero-knowledge proofs. Another name pair sometimes used is Pat and Vanna (after the host and hostess on the Wheel of Fortune television show).

Plod, a law enforcement officer (P for police, also "Officer Plod" from the children's TV show Noddy).

Steve, sometimes used in reference to Steganography.

Trudy, an intruder: another alternative to Mallory.

Trent, a trusted arbitrator, is some kind of neutral third party, whose exact role varies with the protocol under discussion.

Walter, a warden, may be needed to guard Alice and Bob in some respect, depending on the protocol being discussed.

Zoe, often the last party to be involved in a cryptographic protocol.

암호 알고리증 프로세싱 타입

Crypto++ 5.2.1 Benchmarks

Here are speed benchmarks for some of the most commonly used cryptographic algorithms.
All were coded in C++, compiled with Microsoft Visual C++ .NET 2003
(whole program optimization, optimize for speed, P4 code generation), and ran on a Pentium 4
2.1 GHz processor under Windows XP SP 1.  386 assembly routines were used
for multiple-precision addition and subtraction.  SSE2 intrinsics were used
for multiple-precision multiplication.

Also available are benchmarks that ran on an AMD Opteron 1.6 GHz processor under Linux 2.4.21.
Those were compiled with GCC 3.2.2 using -O2 optimization, and inline assembly was used to access the 64-bit multiplication instruction.

Algorithm	Megabytes(2^20 bytes) Processed	Time Taken	MB/Second
CRC-32	2.05e+003	6.399	320.050
Adler-32	4.1e+003	3.525	1161.986
MD2	16	4.006	3.994
MD5	1.02e+003	4.726	216.674
SHA-1	256	3.766	67.977
SHA-256	256	5.758	44.460
SHA-512	64	5.618	11.392
HAVAL (pass=3)	512	4.717	108.544
HAVAL (pass=4)	256	3.695	69.283
HAVAL (pass=5)	256	3.796	67.439
Tiger	128	3.364	38.050
RIPE-MD160	256	4.867	52.599
Panama Hash (little endian)	1.02e+003	3.375	303.407
Panama Hash (big endian)	1.02e+003	4.637	220.832
Whirlpool	64	5.288	12.103
MDC/MD5	256	5.377	47.610
Luby-Rackoff/MD5	64	4.307	14.860
DES	128	5.998	21.340
DES-XEX3	128	6.159	20.783
DES-EDE3	64	6.499	9.848
IDEA	64	3.375	18.963
RC2	64	5.548	11.536
RC5 (r=16)	256	4.286	59.729
Blowfish	256	3.976	64.386
3-WAY	128	3.665	34.789
TEA	128	5.378	23.801
SAFER (r=8)	128	6.279	20.385
GOST	128	3.505	36.519
SHARK (r=6)	128	3.826	33.455
CAST-128	256	5.988	42.752
CAST-256	128	5.889	21.735
Square	128	4.176	30.651
SKIPJACK	128	6.329	20.224
RC6	128	3.385	37.814
MARS	128	4.586	27.911
Rijndael (128-bit key)	256	4.196	61.010
Rijndael (192-bit key)	256	4.817	53.145
Rijndael (256-bit key)	256	5.308	48.229
Rijndael (128) CTR	256	4.436	57.710
Rijndael (128) OFB	256	4.837	52.925
Rijndael (128) CFB	256	5.378	47.601
Rijndael (128) CBC	256	4.617	55.447
Twofish	128	4.075	31.411
Serpent	128	6.069	21.091
ARC4	512	4.517	113.350
SEAL-3.0-BE	1.02e+003	3.485	293.831
SEAL-3.0-LE	2.05e+003	4.937	414.827
WAKE-CFB-BE	512	5.498	93.125
WAKE-CFB-LE	512	3.615	141.632
WAKE-OFB-BE	512	3.855	132.815
WAKE-OFB-LE	512	3.836	133.472
Panama Cipher (little endian)	1.02e+003	4.036	253.717
Panama Cipher (big endian)	1.02e+003	5.317	192.590
SHACAL-2 (128-bit key)	128	6.279	20.385
SHACAL-2 (512-bit key)	128	6.279	20.385
Camellia (128-bit key)	64	3.355	19.076
Camellia (192-bit key)	64	4.437	14.424
Camellia (256-bit key)	64	4.416	14.493
MD5-MAC	1.02e+003	5.528	185.239
XMACC/MD5	1.02e+003	5.999	170.695
HMAC/MD5	1.02e+003	4.726	216.674
Two-Track-MAC	256	4.817	53.145
CBC-MAC/Rijndael	256	4.447	57.567
DMAC/Rijndael	256	4.476	57.194
BlumBlumShub 512	0.25	3.585	0.070
BlumBlumShub 1024	0.125	4.096	0.031
BlumBlumShub 2048	0.0625	5.869	0.011

Operation	Iterations	Total Time	Milliseconds/Operation
RSA 1024 Encryption	27607	5.007	0.18
RSA 1024 Decryption	1050	5.007	4.77
Rabin 1024 Encryption	3008	5.007	1.66
Rabin 1024 Decryption	795	5.007	6.30
LUC 1024 Encryption	23544	5.008	0.21
LUC 1024 Decryption	634	5.007	7.90
DLIES 1024 Encryption	1159	5.007	4.32
DLIES 1024 Encryption with precomputation	1061	5.007	4.72
DLIES 1024 Decryption	350	5.008	14.31
LUCELG 512 Encryption	2433	5.007	2.06
LUCELG 512 Encryption with precomputation	2402	5.007	2.08
LUCELG 512 Decryption	2744	5.007	1.82
RSA 2048 Encryption	11022	5.007	0.45
RSA 2048 Decryption	177	5.028	28.41
Rabin 2048 Encryption	1254	5.007	3.99
Rabin 2048 Decryption	159	5.027	31.62
LUC 2048 Encryption	8756	5.007	0.57
LUC 2048 Decryption	110	5.037	45.79
DLIES 2048 Encryption	260	5.007	19.26
DLIES 2048 Encryption with precomputation	269	5.017	18.65
DLIES 2048 Decryption	60	5.027	83.78
LUCELG 1024 Encryption	532	5.008	9.41
LUCELG 1024 Encryption with precomputation	531	5.007	9.43
LUCELG 1024 Decryption	772	5.007	6.49
RSA 1024 Signature	1053	5.007	4.75
RSA 1024 Verification	27406	5.007	0.18
Rabin 1024 Signature	816	5.008	6.14
Rabin 1024 Verification	3117	5.007	1.61
RW 1024 Signature	951	5.007	5.26
RW 1024 Verification	55580	5.007	0.09
LUC 1024 Signature	644	5.007	7.77
LUC 1024 Verification	24321	5.008	0.21
NR 1024 Signature	2260	5.007	2.22
NR 1024 Signature with precomputation	4376	5.007	1.14
NR 1024 Verification	1964	5.007	2.55
NR 1024 Verification with precomputation	2738	5.007	1.83
DSA 1024 Signature	2301	5.008	2.18
DSA 1024 Signature with precomputation	4444	5.007	1.13
DSA 1024 Verification	2007	5.007	2.49
DSA 1024 Verification with precomputation	2795	5.007	1.79
LUC-HMP 512 Signature	2365	5.007	2.12
LUC-HMP 512 Signature with precomputation	2401	5.008	2.09
LUC-HMP 512 Verification	2312	5.007	2.17
LUC-HMP 512 Verification with precomputation	2269	5.007	2.21
ESIGN 1023 Signature	9837	5.007	0.51
ESIGN 1023 Verification	27679	5.007	0.18
ESIGN 1536 Signature	4898	5.008	1.02
ESIGN 1536 Verification	11940	5.007	0.42
RSA 2048 Signature	178	5.007	28.13
RSA 2048 Verification	11054	5.007	0.45
Rabin 2048 Signature	158	5.028	31.82
Rabin 2048 Verification	1294	5.007	3.87
RW 2048 Signature	176	5.017	28.51
RW 2048 Verification	24521	5.007	0.20
LUC 2048 Signature	110	5.007	45.52
LUC 2048 Verification	9072	5.008	0.55
NR 2048 Signature	511	5.007	9.80
NR 2048 Signature with precomputation	1530	5.007	3.27
NR 2048 Verification	454	5.007	11.03
NR 2048 Verification with precomputation	982	5.008	5.10
LUC-HMP 1024 Signature	522	5.007	9.59
LUC-HMP 1024 Signature with precomputation	527	5.007	9.50
LUC-HMP 1024 Verification	520	5.007	9.63
LUC-HMP 1024 Verification with precomputation	499	5.007	10.03
ESIGN 2046 Signature	4253	5.008	1.18
ESIGN 2046 Verification	11024	5.007	0.45
XTR-DH 171 Key-Pair Generation	2802	5.007	1.79
XTR-DH 171 Key Agreement	1360	5.007	3.68
XTR-DH 342 Key-Pair Generation	777	5.007	6.44
XTR-DH 342 Key Agreement	404	5.018	12.42
DH 1024 Key-Pair Generation	2283	5.007	2.19
DH 1024 Key-Pair Generation with precomputation	2072	5.007	2.42
DH 1024 Key Agreement	1298	5.007	3.86
DH 2048 Key-Pair Generation	512	5.007	9.78
DH 2048 Key-Pair Generation with precomputation	524	5.007	9.56
DH 2048 Key Agreement	368	5.027	13.66
LUCDIF 512 Key-Pair Generation	4688	5.007	1.07
LUCDIF 512 Key-Pair Generation with precomputation	4339	5.007	1.15
LUCDIF 512 Key Agreement	2880	5.008	1.74
LUCDIF 1024 Key-Pair Generation	1057	5.007	4.74
LUCDIF 1024 Key-Pair Generation with precomputation	1037	5.007	4.83
LUCDIF 1024 Key Agreement	776	5.017	6.47
MQV 1024 Key-Pair Generation	2311	5.007	2.17
MQV 1024 Key-Pair Generation with precomputation	4595	5.008	1.09
MQV 1024 Key Agreement	1224	5.007	4.09
MQV 2048 Key-Pair Generation	522	5.007	9.59
MQV 2048 Key-Pair Generation with precomputation	1572	5.007	3.19
MQV 2048 Key Agreement	282	5.017	17.79
ECIES over GF(p) 168 Encryption	759	5.008	6.60
ECIES over GF(p) 168 Encryption with precomputation	1327	5.007	3.77
ECIES over GF(p) 168 Decryption	1062	5.007	4.71
ECNR over GF(p) 168 Signature	1497	5.007	3.34
ECNR over GF(p) 168 Signature with precomputation	2629	5.007	1.90
ECNR over GF(p) 168 Verification	794	5.008	6.31
ECNR over GF(p) 168 Verification with precomputation	1618	5.007	3.09
ECDHC over GF(p) 168 Key-Pair Generation	1536	5.007	3.26
ECDHC over GF(p) 168 Key-Pair Generation with precomputation	2576	5.007	1.94
ECDHC over GF(p) 168 Key Agreement	1474	5.007	3.40
ECMQVC over GF(p) 168 Key-Pair Generation	1529	5.008	3.28
ECMQVC over GF(p) 168 Key-Pair Generation with precomputation	2588	5.007	1.93
ECMQVC over GF(p) 168 Key Agreement	746	5.007	6.71
ECIES over GF(2^n) 155 Encryption	414	5.007	12.09
ECIES over GF(2^n) 155 Encryption with precomputation	1071	5.008	4.68
ECIES over GF(2^n) 155 Decryption	633	5.007	7.91
ECNR over GF(2^n) 155 Signature	827	5.007	6.05
ECNR over GF(2^n) 155 Signature with precomputation	2132	5.007	2.35
ECNR over GF(2^n) 155 Verification	655	5.007	7.64
ECNR over GF(2^n) 155 Verification with precomputation	1232	5.008	4.06
ECDHC over GF(2^n) 155 Key-Pair Generation	806	5.007	6.21
ECDHC over GF(2^n) 155 Key-Pair Generation with precomputation	2124	5.007	2.36
ECDHC over GF(2^n) 155 Key Agreement	780	5.007	6.42
ECMQVC over GF(2^n) 155 Key-Pair Generation	816	5.007	6.14
ECMQVC over GF(2^n) 155 Key-Pair Generation with precomputation	2116	5.008	2.37
ECMQVC over GF(2^n) 155 Key Agreement	660	5.017	7.60

Notes

• 
  Crypto++ 5.2.1 Benchmark Average for this platform: 135.54. This number
  is computed by taking the geometric mean of the number of MB/second of each cipher,
  hash function, and MAC, and operations/second of each asymmetric operation listed above.
  
• 
  RSA and LUC use 17 as the public exponent.
  
• 
  DH and ElGamal encryption and decryption use short exponents to save time.
  The size of the secret exponents were chosen so that a meet-in-the-middle
  attack would be slower than the general discrete log algorithm (NFS). The
  sizes used were:
  
  

  modulus	exponent
  512	120
  1024	164
  2048	226

  
  
• 
  EC means elliptic curve.  Operations in GF(2^n) are implemented using
  trinomial basis.  Note that compared to other algorithms listed here,
  Crypto++'s implementation of EC over GF(2^n) is less optimized.
  
• 
  All tests were done by repeating the crypto operations over small blocks
  of random data.  In practice you will likely see slower
  speeds because time is needed to transfer data to and from memory.
  
• 
  For the ciphers that specify big endian byte order, the timing data
  listed include time needed to convert to and from little endian
  order.  For some ciphers (WAKE and SHA) this is a large fraction (up
  to 25%) of the total time.
  
• 
  The RSA, RW, DH, MQV, and elliptic curve schemes come from the IEEE P1363
  standard. For more info see
  http://grouper.ieee.org/groups/1363/index.html.
  
• 
  Precomputation means using a table of 16 precomputed powers of
  each fixed base to speed up exponentiation.
  
• 
  Tiger, SHARK, SHA-384, and SHA-512 are designed to take advantage of 64-bit
  word operations.
  Their relatives speeds can be expected to be much higher if the benchmarks
  were done on a 64-bit CPU.
  
• 
  Source code for these benchmarks is available as part of the Crypto++ library.
  

---

Written by: Wei Dai <webmaster@weidai.com> Last modified: 7/23/2004

Security Services

Kerberos는 Network Authentication Protocol이다. 클라이언트와 서버가 있을 경우 중간에서 클라이언트의 Authentication 서비스를 해주는 것이 바로 Kerberos이다. Kerberos는 MIT 의 ATHENA 프로젝트에 의해 개발되었다.

아래에서는 Authentication 방법과 Kerberos 에 쓰이는 방식을 설명하였다. 순서대로 simple authentication 방법과 좀더 안전한 Authentication 방법 그리고 마지막으로 이러한 이론을 이용하여 Kerberos에서 어떻게 메시지들이 오가는지를 설명하였다.

Simple Authentication

먼저 간단한 인증 과정을 살펴 보자. 위에서 보면 C와 V가 있는데, C는 클라이언트를 나타내고 V는 서버를 일컫는 말이다. 그리고 또 하나 등장하는 것이 AS 인데, 여기서 AS(Authentication Server)는 중앙 DB에 모든 사용자들의 암호를 기억하고 있게 된다. 덧붙여 설명하자면 이 AS는 각 서버와 유일한 비밀 키를 공유하게 되는데, 이러한 키는 사전에 안전한 방법으로 분배되어 있어야 한다. 예를 들어 관리자가 직접 키를 디스켓에 담아가는 방식으로 말이다. 그럼 이것을 기본으로 위의 시나리오를 살펴보기로 하자.

- 1단계 : 먼저 클라이언트는 AS에게 자신의 ID와 자신이 통신하고자 하는 서버의 ID, 그리고 사용자의 암호를 포함하는 메시지를 보낸다.

- 2단계 :

그러면 AS는 보내온 사용자의 ID와 암호를 가지고 자신이 가지고 있는 DB에서 그것이 유효한지를 확인한다. 그리고 이 사용자가 통신하고자 하는 서버에 접근 권한을 가지고 있는지 또한 확인하게 된다. 이러한 과정을 거친 후에 사용자에게 인증되었다는 표시로 Ticket이라는 것을 보내주게 된다. 이 Ticket은 위에서도 보는 바와 같이 클라이언트 ID, 네트워크 주소, 서버의 ID 정보를 AS와 서버가 공유하고 있는 비밀 키를 이용하여 암호화 하여 클라이언트에게 전해진다.

- 3단계 :

이 Ticket을 받은 클라이언트는 자신의 ID와 Ticket을 함께 서버에게 보내주게 된다. 이렇게 되면 서버는 Ticket이 자신의 비밀키로 암호화 되어 있기 때문에 그것을 복 호화 할 수 있다. 그리고 서버는 복 호화한 클라이언트의 ID와 그냥 날아온 클라이언트의 ID을 비교해 보고 그것이 같으면 서버는 이 사용자가 인증된 사용자라고 인식하게 되는 것이다.

-보안 측면

Ticket에 보면 네트워크 어드레스(AD_C)가 있는데 그것은 공격자가 Ticket을 가지고 다른 워크스테이션에서 접근하는 것을 막기 위한 것이다. 메시지(2)에서 보면 AS 가 클라이언트에게 Ticket을 보내주는데 만약 그것을 공격자가 가로채어 다른 워크스테이션에서 그 Ticket을 가지고 클라이언트 ID을 이용하여 서버에 접근하고자 할 때, 서버는 네트워크 어드레스를 보고 이것이 맞는지 틀리는지를 확인하게 된다.

-단점

1. 이 시나리오에서는 만약 어떤 사용자가 메일을 체크 하고자 할 때 계속해서 암호를 넣어주어야 하는 불편이 생긴다. 즉 한번 받은 Ticket을 재 사용 할 수 없다는 문제가 생기게 된다.

2. 두 번째 문제점은 메시지 (1)에서 보듯이 암호가 그냥 일반 텍스트로 전송이 된다는 것이다. 이렇게 되면 공격자가 이 정보를 가로채어 이용할 수 있는 여지를 남기게 된다.

A more secure Authentication Dialogue

위와 같은 문제점들을 해결하고자 나온 것이 아래와 같은 시나리오이다. 첫 번째 시나리오와 틀려진 점이라면 바로 TGS (Ticket Granting Server)을 두었다는 것이다. 이 시나리오에서는 AS는 단순히 인증만을 담당하게 되고 Ticket을 발급해 주는 것은 TGS가 맡게 되는 것이다. 여기서 TGS는 AS에서 인증 받은 클라이언트에게만 Ticket을 발급하게 된다.

Once per user logon session:

- 1단계 :

사용자는 자신의 ID와 TGS ID를 TGS 서비스 요청을 위해 함께 AS 에게 전송한다.

- 2단계 :

사용자의 암호를 이용하여 생성한 키를 이용하여 Ticket 을 암호화(Encryption)하여 클라이언트에게 전송한다. 이것을 받은 사용자는 역시 마찬가지로 자신의 암호(Password)를 이용하여 키를 생성하여 날아온 Packet을 풀어(Decryption) Ticket을 얻는다.

Ticket에 보면 Ticket이 만들어진 날짜와 시간정보를 포함하는 Timestamp 값이 들어가는데, 그것은 어떤 공격자가 Ticket을 캡쳐하여 이용하려는 것을 막기 위함이다. 그리고 Ticket-granting ticket은 AS와 TGS가 공유하고 있는 비밀키로 암호화 되어 있기 Ticket의 번 갈음(alternation)을 막을 수 있다. 그리고 다시 Ticket 은 사용자의 암호(password)로 암호화(encryption)되어 있기 때문에 승인된 사용자만이 쓸 수 있게 된다(Authentication 역할).

Once per type of service :

　

- 3 단계 :

여기서는 클라이언트가 service-granting ticket을 요구한다. 이때 사용자는 자신의 ID와 접속하고자 하는 서버의 ID을 전송하게 된다.

- 4 단계 :

이 때, TGS는 들어오는 Ticket을 Decryption하고 그 안에 들어있는 자신의 ID을 확인한다. 이 절차가 끝나면, TGS는 lifetime의 기한이 만료되었는지를 체크 한다. 그리고 나서 사용자를 인증하기 위해 Ticket안에 있는 사용자 ID와 네트워크 어드레스를, 같이 전송되어온 사용자의 ID와 네트워크 어드레스와 비교한다. 여기서 사용자가 인증되면 service-granting ticket을 전송하여 준다.

여기서 전송되어지는 service-granting ticket은 TGS와 서버가 공유하고 있는 비밀키로 암호화 하여 전송되어진다.

Once per service session :

- 5 단계 :

그리고 마지막으로 5단계에서는 클라이언트의 ID와 service-granting ticket을 가지고 사용자를 인증하게 된다.

Kerberos Version 4 Message Exchange

위와 같은 원리를 이용하여 kerberos는 아래와 같은 메시지를 주고 받으면서 동작한다.

(a) Authentication Service Exchange : To Obtain Ticket-Granting Ticket

앞서와 달리 여기서 추가된 것은 1단계에서는 Timestamp가 추가되어 시간에 따른 확인이 가능하게 하였고, 2단계에서는 사용자의 ID와 네트워크 어드레스 그리고 TGS의 ID 또한 Timestamp와 lifetime이 추가되었다. 그리고 클라이언트와 TGS가 공통으로 쓸 비밀키도 이때 전송되어 진다. 이것은 이 키를 사용하는 사람이 C라는 것을 나타내게 되는 것이다.

(b) Ticket-Granting Service Exchange : To Obtain Service-Granting Ticket

여기서 추가된 것은 3단계에서 Authenticator 정보가 추가 되었는데 이 Authenticator 안에 들어있는 정보와 Ticket안에 들어있는 정보를 비교하여 사용자를 인증하는 역할을 하게 된다. 4단계에서는 이렇게 인증된 사용자에게 service-granting ticket을 넘겨주게 되는데, 이때 클라이언트와 TGS가 공유하고 있는 비밀 키를 이용하여 암호화(Encryption)해서 전송하여 준다.

(c) Client/Server Authentication Exchange : To Obtain Service

마지막으로 클라이언트는 받은 service-granting ticket과 Authenticator을 같이 접속하고자 하는 서버에게 전송하게 되고 이것을 가지고 서버는 이 사용자가 인증 받은 사용자인지를 판단하게 된다.

OTP로 강도 높은 보안 환경 구축 가능

내부 정보 유출 차단·높은 보안성 유지 … 기존 인증·호환성 고려해야

김해숙

퓨쳐시스템 전략기획팀 책임연구원

kimhs@future.co.kr

지난 5월에 발생한 인터넷 뱅킹 해킹 사고 이후로 전자 금융거래에 대한 불안감이 높아진 가운데, 정부가 내놓은 전자금융거래 종합 대책에 보면 일반인들에게는 낯설은 OTP(One Time Password: 일회용 패스워드 발생기)라는 단어가 눈에 띈다. 보안등급에 따라서 1일 이체 한도를 다르게 제한하겠다는 것이 일차적인 내용인데, 보안등급을 분류하는 기준을 살펴보면 ‘OTP 보유자 또는 HSM(공인인증서 복사방지 스마트카드 및 USB 저장장치) + 보안카드 보유자’를 가장 높은 등급인 1등급으로 분류해 놓았다. 도대체 OTP가 뭐길래 가장 높은 보안 등급으로 분류된 것일까?

여기서는 OTP에 대한 개념 소개와 현재 사용되고 있는 OTP 관련 기술에 대해서 살펴보자. <편집자>

우선 OTP는 한마디로 말하면, 우리가 능숙하게 사용하고 있는 사용자 아이디/패스워드(ID/Password) 기반 사용자 인증 시스템에서 고정된 패스워드(비밀번호) 대신에 매번 다른 패스워드를 입력토록 하는 패스워드를 OTP라고 하고, 확장된 의미로 이러한 패스워드를 생성해 주는 장치를 OTP라고 부르기도 한다. 콘솔로 로그인하는 시스템에서는 사용자 ID와 패스워드에 대한 도용 가능성이 낮지만, 고정된 패스워드를 사용해서 리모트로 접속하는 환경에서는 스니핑 공격을 통해서 패스워드 재사용 공격이 용이하기 때문에 이를 해결하기 위해 고안된 것이 OTP 솔루션이다.

사용자 인증이란?

서두에서 언급했던 것처럼 지난 5월에 발생한 인터넷 뱅킹 해킹 사고는 해킹 프로그램을 통해서 인터넷뱅킹 ID, 패스워드, 공인인증서 비밀번호, 보안카드 코드번호 등을 알아낸 뒤 범행을 저지를 것으로, ID와 패스워드 도용 사례는 가장 빈번한 해킹 방식이다. 그렇다면 아이디/패스워드 도용을 막을 방법은 무엇일까? 정확한 사용자 인증(authentication)이 해답이다. 사용자 인증 과정을 통해서 특정 사용자를 유일하게 식별할 수 있다면, 본인이 아닌 제 3자가 ID를 도용해서 발생할 수 있는 피해를 줄일 수 있기 때문이다.

사용자 인증이란 어떤 사람이 실제로 신고한(또는 주장하는) 바로 그 사람인지를 판단하는 과정으로, 인터넷 등에서의 사용자 인증은 대개 로그온 시에 사용하는 사용자 ID와 패스워드를 통해서 이루어진다.

그러나, 사용자 ID와 패스워드는 외우기 쉬워야 한다는 단점 때문에 추측해서 알아내거나 스니핑 공격 등으로 알아내는 등 노출 가능성이 높기 때문에 안전하지 못 하다. 패스워드 노출 가능성을 줄이고 패스워드가 노출돼도 ID 도용 가능성을 낮추기 위해 많은 경우에 ‘이중 요소 사용자 인증’ 방식이 많이 활용되고 있다.

사용자 인증에 사용되는 요소는 크게 사용자가 알고 있는 내용(ex. 패스워드), 사용자가 가지고 있는 물건(ex. 은행 현금 인출용 카드, OTP 토큰, 공인인증서), 사용자의 신체적인 특징(ex. 홍채, 지문, 정맥 및 얼굴 형태 인식) 등 세 가지 방식에 기반하게 된다.

앞에서 말한 것처럼, 사용자 ID와 패스워드를 이용한 사용자 인증 방식은 ID 도용 가능성이 높기 때문에 세 가지 사용자 인증 요소를 혼합한 이중 요소 사용자 인증(이중 인증, two-factor authentication)이 점차 대중화되고 있으며 대표적인 것이 ‘공인인증서 + 보안카드’, 비밀번호를 입력하는 OTP 토큰 등이 있다.

OTP 구현 방식

이중 요소 사용자 인증의 대표적인 방법인 OTP는 기본적으로 암호학적인 아이디어를 바탕으로 고안된 것으로 보안성이 높고 사용하기에 편리한 방식이다. 매번 다른 패스워드를 사용하기 때문에 고정된 패스워드를 사용하는 방식과 달리 패스워드 재사용 공격이 불가능하고, 암호학적 알고리즘을 사용하기 때문에 기존에 사용된 패스워드로부터 다음에 사용될 패스워드를 예측하는 것이 불가능하며, 따라서 안전하다.

<그림 1>에서와 같이 OTP 토큰 또는 사용자 PC에 저장된 OTP용 프로그램에 사용자 비밀번호와 일회용 비밀번호 생성용 입력값을 입력하면, 암호 알고리즘을 사용해서 일회용 패스워드를 생성하게 된다.

여기서 들어가는 입력값(위의 그림에서 시퀀스 카운터 부분)을 매번 다른 값으로 입력해야 일회용 패스워드가 생성되며, 이 입력값을 어떤 값으로 입력하는가에 따라 시간 동기화(Time Synchronous) 방식, 첼린지 리스펀스(challenge-response) 방식, 이벤트 동기화(Event Synchronous) 방식으로 분류된다. 지금부터 고전적인 OTP 방식인 S/Key 방식과 위에 언급한 세 가지 OTP 방식에 대해 기술적인 특징을 살펴 보자.

1) 고전적인 OTP : S/Key 방식

S/Key 방식은 공중망을 통해 원격 시스템에 로그인할 때 중간에서 패킷을 스니핑해 재사용하는 재사용 공격을 방지하는 간단한 시스템으로 매번 패스워드가 바뀌는 방식이기 때문에 고전적인 OTP 방식이라고 할 수 있다. S/Key는 암호 알고리즘의 일종인 해쉬 함수(Hash function)을 이용하는 방식으로 사용하기에 간단하고 어떤 비밀 정보도 호스트에 남지 않기 때문에 안전한 시스템이다.

해쉬 함수는 주로 MD4, MD5 또는 SHA1이 사용되는데 이러한 해쉬 함수는 불가역적인 성질을 가지고 있어 해쉬값을 알고 있더라도, 원래의 입력값을 알아내기 힘들며, 또한 같은 해쉬값을 갖는 새로운 입력값을 찾아내는 것도 힘든 특징을 가지고 있다. 따라서, 악의를 가진 해커가 네트워크상에서 해쉬 함수로 생성한 패스워드를 스니핑한다고 해도, 그 해쉬값을 갖는 원문 패스워드를 알아내거나 새로운 패스워드를 만들어 내기 힘들기 때문에 간단하면서도 안전하게 이용할 수 있다.

S/Key는 아래 그림에서와 같이 사용자의 입력값에 해쉬 함수를 정해진 회수 ‘n’번만큼 적용해서 1회용 패스워드를 ‘n’개 생성한 후 맨 마지막에 생성된 패스워드 값을 인증서버와 사용자(또는 사용자 S/W)가 나눠 갖게 된다.

그 후 <그림 3>에서와 같이 사용자는 미리 생성된 패스워드 중에서 ‘n-1’번째 패스워드를 사용해서 사용자 인증을 시도하면, 인증서버는 사용자로부터 받은 패스워드에 해쉬함수를 1회 적용해서 나온 값이 인증서버에 있는 패스워드값(n번째 패스워드값)과 같은지 비교한 후 인증 성공/실패를 판단하게 된다. 인증에 성공하게 되면 인증서버는 ‘n-1’번째를 새로운 패스워드로 저장하고 두 번째 패스워드부터는 해쉬 함수 적용 회수를 순차적으로 한번씩 적게 적용한 값을 패스워드로 사용하게 된다.

인증을 여러 번 수행하게 되면 해쉬 함수 적용 가능 회수가 하나씩 줄어들게 되므로 어느 시점에 다다르면 패스워드를 재초기화 시켜 줘야 하는 불편이 있으나, PC 등에서 저장해 놓거나 미리 계산해 놓은 후에 사용할 수 있다는 장점을 가지고 있다.

2) OTP 챌린지 리스펀스 방식

챌린지 리스펀스 방식은 임의의 난수를 암호 알고리즘의 입력값으로 사용해서 일회용 패스워드를 생성하는 방식으로, 인증 서버 또는 애플리케이션이 임의의 난수값을 생성해서 사용자에게 보내면(Challenge), 사용자는 이 난수값을 일회용 패스워드 생성 토큰 또는 소프트웨어에 입력하고, 여기서 나오는 출력값을 일회용 패스워드로 입력해(Response) 사용자 인증이 수행된다. 이 과정에서 인증 서버가 보내 준 난수값은 사용자의 비밀키(또는 토큰 입력용 패스워드)로 암호화되며, 사용자가 입력한 일회용 패스워드를 가지고 인증 서버는 동일한 난수값(Challenge)와 등록된 사용자 정보를 이용해서 OTP를 생성한 후 사용자의 리스폰스와 비교해서 사용자 인증을 해 준다.

챌린지 리스펀스 방식은 사용자 인증을 수행할 때마다 새로운 난수값을 챌린지로 사용하기 때문에 ID 도용 의도를 가진 공격자는 매번 부트 포스(Brute force) 공격을 새로 수행해야 한다는 점에서 안전하다고 할 수 있다. 그러나, 공격자가 네트워크를 모니터링해 사용자 인증에 성공한 챌린지 리스펀스 값을 모두 알게 될 경우 이를 이용해 이그조스티브 키 서치(exhaustive key search) 방법으로 사용자의 비밀키를 찾아낼 수도 있다. 따라서, 챌린지 리스펀스 방식에 사용하는 암호 알고리즘은 이그조스티브 키 서치가 매우 어려워서 실질적으로 비밀키를 알아낼 수 없는 알고리즘을 사용해야 한다.



3) OTP 시간 동기화 방식

시간 동기화(Time Synchronous) 방식은 챌린지 리스펀스 방식이 갖고 있는 단점인 사용자의 번거로움과 사용자 ID/패스워드 기반 프로토콜/어플리케이션과 호환이 용이하지 못한 점을 개선하자는 의도로 개발된 것으로 RSA의 시큐어아이디(SecurID)가 대표적이다. 챌린지 리스펀스 방식과 달리, 기존의 사용자 ID/패스워드 기반 인증 시스템에서 패스워드 검증 절차만 변경하면 되므로, 챌린지 리스펀스 방식에 비해 간단하게 사용이 가능하다.

시간 동기화란 이름에서 알 수 있듯이 시간 동기화 방식은 챌린지 리스펀스 방식이 임의의 난수값을 일회용 비밀번호의 입력값으로 사용하는 것과 달리, 시간을 일회용 비밀번호의 입력값으로 사용한다. 따라서, 챌린지 리스펀스 방식에서 인증 서버가 보내주던 챌린지 전달 절차 없이 사용자가 일회용 비밀번호를 생성해 PIN(사용자 비밀번호, 비밀키)과 함께 인증 서버에 전달하면, 서버는 PIN을 인덱스로 하여 해당 비밀키를 찾고, 생성된 일회용 패스워드가 수신한 것과 일치하는 지를 확인한다

시간 동기화 방식은 인증 서버와 사용자 모두 같은 시간을 일회용 비밀번호의 입력값으로 넣어야 하기 때문에 인증 서버와 사용자 토큰 사이에 시간이 일치하지 않으면 사용자 인증에 실패할 수 밖에 없다. 일회용 비밀번호의 입력값을 서버로부터 받지 않는 장점이 있는 반면 서버와 사용자 토큰의 정보를 일치시켜야 하는 단점을 안고 있어 사용자 수가 많은 경우 여러 개의 시간을 동시에 일치시키기 힘들기 때문에 문제 발생 가능성이 있다. 따라서, 많은 경우 시간의 오차 범위를 설정해서 그 범위 안에서는 인증이 성공하도록 허용하고 있다.

또한, 대체로 1분, 2분 단위로 일회용 패스워드가 생성되기 때문에 인증 실패 시에는 인증 재시도를 위해 기다려야 하는 불편함과 일정 시간 동안 입력하지 못하면 중간에 패스워드가 바뀌어 다시 입력해야 하는 점 등도 단점으로 꼽히고 있다.

4) OTP 이벤트 동기화 방식

이벤트 동기화 방식은 시간 동기화 방식이 갖고 있는 단점을 극복한 방식으로 인증서버와 사용자 토큰 간에 시간 정보를 일치시킬 필요가 없으면서도 잘 알려진 암호 알고리즘을 사용하기 때문에 안전성이 높은 방식이다.

이벤트 동기화 방식은 시간 정보 대신에 인증서버와 인증 횟수(Counter) 기록을 공유하고 인증 횟수를 일회용 패스워드 생성시 입력값으로 활용한다.

예를 들어 보자. 홍길동이 시큐어컴퓨팅사의 ‘세이프워드 골드(Safeword Gold) 2000 OTP’를 사용한다면, 우선, 인증 서버와 세이프워드 OTP는 카운터를 ‘0’으로 세팅한다. 홍길동이 일회용 비밀번호를 생성하기 위해 세이프워드 OTP의 버튼을 누르면 카운터 값이 1로 증가하고, 이 값을 홍길동이 입력한 비밀키를 이용해서 암호화한다. 암호화된 결과값이 일회용 패스워드로 화면에 나타나고, 이 값을 시스템에 입력하면 인증서버에 전달된다.

일회용 패스워드를 전달받은 인증서버는 홍길동의 인증 기록으로부터 카운터 값을 알아내고 이 값을 1로 증가 시킨 후, 홍길동의 비밀키를 활용해 일회용 패스워드를 복호화한 후 홍길동으로부터 받은 카운터 값과 인증서버의 카운터 값이 같은지 확인해서 인증 성공/실패 여부를 판단한다. 그 후 매 인증시마다 OTP와 인증서버의 카운터값은 1씩 증가되어 저장되기 때문에 카운터 값이 매번 일치하고 성공적인 인증이 수행될 수 있다.

시간 동기화 방식이 인증 서버와 OTP 토큰 사이에 시간을 일치시켜야 하는 것처럼, 이벤트 동기화 방식에서는 카운터를 인증 서버와 OTP 토큰 사이에 일치시켜야 정상적으로 인증이 수행된다. 이벤트 동기화 방식에서 생길 수 있는 문제점은 사용자가 실수 또는 호기심에 의해 일회용 패스워드를 생성해 인증 서버의 카운터와 OTP 토큰의 카운터가 맞지 않는 경우에 발생할 수 있다.

이 경우 세이프워드 OTP는 인증 서버에서 카운터의 오차 범위(카운터~카운터 +16 범위를 일반적인 오차 범위로 허용함)를 정해 범위 내에 들어올 경우에 사용자 인증을 허용하는 방법과 오차 범위를 벗어날 경우 연속된 2번의 일회용 비밀번호가 올바른 값으로 판단될 경우 사용자 인증을 허용하는 방식으로 문제점을 극복하고 있다.

따라서 시간 동기화 방식이 관리자가 수동으로 시간을 맞추는 불편함이 있던 것을 극복한 것이 이벤트 동기화 방식이다.



OTP 도입시 고려 사항

A 협회의 경우 각 회원사의 자금 담당자가 자금 중계용 비공개 웹사이트를 통해서 자금 이체를 하도록 허용하고 있다. 이 협회의 경우 각 회원사의 자금 담당자가 빈번하게 교체되고 있으나 각 담당자별로 사용자 ID/패스워드를 매번 관리하는 것이 힘들어서 각 회원사별로 고정된 사용자 ID와 고정된 패스워드를 계속 사용하고 있어서 패스워드 고유의 역할을 하지 못하고 있는 실정이었다. A 협회는 OTP 토큰 도입으로 각 회원사의 자금 담당자가 A 협회의 비 공개 웹사이트 접근시에 OTP 사용을 의무화함으로써 보안성을 강화할 수 있었다.

B 사의 경우는 협력 업체와 함께 일하는 현장 사무실이 많고, 현장 사무실에서는 사용되는 PC는 모든 사람이 공용으로 사용하는 경우가 많아서 내부 정보 유출의 위험이 높은 상태였다. 이 회사는 OTP 토큰을 도입함으로써 현장 사무실의 컴퓨팅 환경과 상관 없이 필요한 애플리케이션을 높은 보안성을 유지하면서 사용할 수 있게 되었다.

이처럼 사용자 인증 강화로 인해서 보안 강화, 사용자 접근 제어 기능 및 사용자 관리 기능을 제공하는 OTP 솔루션 도입시에는 다음과 같은 점들을 고려해야 한다.

우선 래디우스와 같이 사용자 인증을 위해 기존에 구축돼 있는 인증 서버와 쉽게 연동이 가능한가, 그리고 사용 중인 그룹웨어 등 애플리케이션과 얼마나 호환성을 제공하는지 살펴봐야 한다. 앞에 예를 들었던 챌린지 리스펀스 방식은 기존의 ID/패스워드 기반 프로로콜이나 애플리케이션에 사용하기 위해서는 수정해야 할 부분이 많기 때문에 구축이 어려운 단점이 있다.

또한 얼마나 관리가 용이한가도 살펴봐야 할 요소다. 앞에 예를 든 시간 동기화방식은 인증서버와 OTP 토큰 사이에 시간 정보를 일치시키기 위한 관리자의 노력이 필요하며 사용자가 많은 환경에서는 이 또한 부담이 될 수 있다.

그 외에도 사용되는 OTP 알고리즘의 특징을 파악해 보안 강도가 높고, 사용자가 사용하기 편리한 솔루션을 선택해야 한다.

Cryptology 암호학

암호학은 크게 두 분야로 나눌 수 있다. 암호를 제작하는 분야와 만들어진 암호를 해독하기 위한 분야가 그 것이다.

암호학(cryptology)

• Cryptography : 암호의 구축과 작성을 위한 암호학 분야.


• Cryptanalysis : 암호를 분석하여 해독하기 위한 암호학 분야.     

암호 사용의  Model

평문(plain text): 아직 암호화 되지 않은 원문.

암호문(cipher text): 평문이 암호화(encryption) 과정을 거쳐 암호화된(ciphered) 결과



암호화(encryption): 평문을 암호문으로 바꾸는 과정.

복호화(decryption): 암호문(cipher text)을 평문(plain text)으로 되돌리는 과정.

암호화 키(encryption key): 평문을 암호문으로 변경하기 위한 비밀번호(key).

복호화 키(decryption key): 암호문을 평문으로 복원하기 위해 사용하는 비밀번호(key).

암호 사용 모델:

   평문  ------>  암호문   =========> 암호문 --------> 평문

               암호화                         통신                        복호화

암호화는 통신의 발신자(송신자, sender)가 실행하는 내용이고,

복호화는 통신의 수신자(receiver)가 원문으로 복원하기 위하여 실행하게 된다.

참고: 복호화 과정은 수신자가 정당하게 암호문을 평문으로 복원하는 것을 의미하는 한편, 암호분석(cryptanalysis)는 중간에서 가로챈(예를 들면, 도청 등을 통하여) 암호문을 복호화 키가 없이 평문으로 복원하려는 시도 및 과정을 의미한다.

암호의 필요성

정보통신의 발달과 함께, 정보의 소통량과 전달, 이동 등의 양이 급증하게 되었다. 또한 소통되는 정보의 내용도 사무자동화와 함께, 군사기밀, 정부정책문서, 사업기밀 등 중요한 내용 등을 포함하게 되었다. 그러므로, 정보를 보내는 발신자와 정보를 받아보는 수신자 모두 도청(eavesdropping)을 당하지 않기 위해 비밀번호(key, 키)를 사용하여 발신 원문을 암호문으로 바꾸어 전송하고 수신자는 수신된 암호문을 복원하여 평문으로 고치는 과정을 필요로 하게 되었다.

인터넷 등의 발달로 전자상거래 등이 보편화되고 사업형태도 변모하게 되어 암호학의 사용은 더욱 중요도를 높여가고 있으며, 국내에서의 암호학의 발전도 시급한 실정이다. 암호를 이용한 응용을 살펴보면,

• 전자상거래(electronic business): 인터넷을 이용한 전자 신용 상거래.


• 전자 인증(authentication): 인터넷 등 통신을 이용한 인증체계.


• 디지털 서명(digital signature): 통신을 이용한 서명 방식.


• 전자 화폐(electronic money, digital money, cyber cash, virtual currency 등): 통신에 의한 전자상거래에서 사용할 수 있는 가상 화폐.

이 외에도 스마트 머니 등 다양한 암호화가 필요한 통신 대상 들이 급증하고 있고, 상업 형태도 급변하고 있는 실정이다.

암호의 종류

시대별 구분

• 고전암호 (약 기원전 400년 ~ 1920년경): 대입암호, 치환암호 등 일상적으로 사용하는 글자, 단어 등을 단순히 다른 기호로 대치하는 형태의 암호. 시이저(Caesar)가 처음 사용한 것으로 알려져 있음.


• 기계암호 (1920 ~ 1950): 세계대전을 치루는 기간 동안의 시기에 전쟁을 위한 군사기밀의 통신을 위한 암호의 사용으로 발달한 암호. 특히, 독일이 암호화를 위한 기계장비를 개발한 것이 암호학 발달에 큰 영향을 미침. 또 그에 반하여, 암호의 해독기술도 따라 발달하게 됨.
  
  "도라,도라,도라" 등 암호분석에 의하여 전쟁을 승리한 내용을 영화화한 영화도 제법 많이 있음.


• 현대암호: 기계식 암호의 해독도 컴퓨터의 발달과 함께 용이해져서 수학적 어려움을 이용한 암호의 형태로 변형됨. 대표적인 현대암호로 DES암호와 RSA암호가 있음.

기능별/형태별 구분

• 대칭암호(symmetric cipher):
  
  암호화 키와 복호화 키가 같은 암호체계. 두 개의 키(key)가 같으므로 원하지 않는 사람에게로의 키의 유출을 막기 위하여서는 키를 비밀리에 사용하여야 함. 그래서 비밀키 암호(secret key cipher)라고도 함.
  
  대표적인 암호로 DES 암호가 있음.


• 비대칭암호(asymmetric cipher):
  
  암호화 키가 복호화 키와는 다른 암호체계. 그러므로, 암호화 키는 공개하여도 도청의 염려가 없음. 그래서 공개키 암호(public key cipher)라고도 함. 전자상거래 등에 이용됨.대표적 암호로  RSA 암호가 있음.

암호의 분석/공격/해독

암호의 해독을 위한 공격법으로

• 전수공격(keyexhaustion): 가능한 모든 키를 실행해보는 암호해독방법.


• 통계적분석(statistical analysis): 통계적으로 개연성이 큰 키를 만들어내는 암호해독법.


• 수학적분석법(mathematical analysis): 가장 전문적인 암호해독 방법. 이는 암호학의 발달로 인해 암호가 수학문제와 이론 등을 이용하여 제작되었기 때문에 해독법의 개발을 위해서는 수학적 이론이 필요하게 된 탓.

DES 알고리즘

- 컴퓨터와 통신기술의 발달로 인해 암호의 사용이 불가피하게 됨.

- 1973년 5월, 미국의 NBS(National Bureau of Standards, 국립 표준국)가 document의 저장과 전송 등을 위한 암호 알고리즘을 공모.

- 1975년, IBM(Internation Business Machines, Inc. 아이비엠)의 연구원 W. Tuckman 과 C. Meyer 가 DES(Data Encryption Standard) 암호 알고리즘을 제안.

- 1976년 IBM이 지적소유권을 포기.

- 1977년 1월 NSA(National Security Agency)의 검토를 거쳐 NBS가 DES를 표준 암호 알고리즘으로 선정함.

- 매 5년마다 재인증. 1983년과 1994년 재인증을 받아 표준 암호로 건재하게 사용되고 있음.

* DES 암호는 그 내용을 공개하여 <암호학의 발달>을 가져오고 또한 컴퓨터의 발달에 따라 DES를 대신할 알고리즘 개발이 한창 진행 중임.

RSA 공개 키 암호

1976년, Diffie & Hellman 이 공개키암호의 사용을 제안.

1978년, MIT 교수 Rivest, Shamir, Adleman 등 3명은 블록암호로서 공개키 암호를 개발. 그들의 이름을 따서 RSA 암호로 지칭함.

RSA 암호는 기본적인 정수론을 이용한 암호로 가장 널리 사용되고 있다.

관련 수학적 배경

• 인수분해.


• 합동.


• Euler 함수.


• Euler 정리( 또는 Fermat 정리).

인수분해 (Prime Factorization)

합동 (Congruence)

   임의의 2 개의 정수 a 와 b 가 정수  n을 기준으로 서로 합동이다

   <=> a 와 b 는 n으로 나누었을 때 나머지가 같다.

   <=> a - b = n 의 배수 = q. n  for some integer q.

   <=>