TinyECCK : Efficient Implementation of Elliptic Curve Cryptosystem over GF$(2^m)$ on 8-bit Micaz Mote

TinyECCK : 8 비트 Micaz 모트에서 GF$(2^m)$상의 효율적인 타원곡선 암호 시스템 구현

Abstract

In this paper, we revisit a generally accepted opinion: implementing Elliptic Curve Cryptosystem (ECC) over GF$(2^m)$ on sensor motes using small word size is not appropriate because partial XOR multiplication over GF$(2^m)$ is not efficiently supported by current low-powered microprocessors. Although there are some implementations over GF$(2^m)$ on sensor motes, their performances are not satisfactory enough due to the redundant memory accesses that result in inefficient field multiplication and reduction. Therefore, we propose some techniques for reducing unnecessary memory access instructions. With the proposed strategies, the running time of field multiplication and reduction over GF$(2^{163})$ can be decreased by 21.1% and 24.7%, respectively. These savings noticeably decrease execution times spent in Elliptic Curve Digital Signature Algorithm (ECDSA) operations (Signing and verification) by around $15{\sim}19%$.

본 논문에서는 "작은 워드 크기를 사용하는 센서모트에서는 GF$(2^m)$상의 partial XOR 곱셈연산이 저전력 마이크로프로세서에 의하여 효율적으로 지원되지 않기 때문에 GF$(2^m)$에 기반을 둔 타원곡선 암호시스템의 소프트웨어 구현은 비효율적이다"라는 일반적으로 인정된 의견을 검증한다. 비록 센서모트에서 GF$(2^m)$에 기반을 둔 몇 가지의 소프트웨어 구현은 있지만, 이것들의 성능은 센서네트워크에서 사용할 만큼 충분하지 못하다. 기존 구현들의 성능 저하는 유한체 곱셈과 감산 연산에서 발생하는 중복된 메모리 접근에서 기인한다. 따라서 본 논문에서는 유한체 곱셈과 감산과정에서 발생하는 불필요한 메모리 접근을 줄일 수 있는 몇 가지 방법을 제안한다. 제안한 방법을 통하여, GF$(2^{163})$상의 유한체 곱셈과 감산의 수행시간을 각각 21.1%와 24.7% 줄일 수 있으며 이것은 Elliptic Curve Digital Signature Algorithm (ECDSA)의 sign과 verify 연산 시간을 약 $15{\sim}19%$ 단축시킬 수 있다.

Ⅰ. 서론

대칭키 기반의 암호 프로토콜은 제약된 기능성으로 인하여 센서 네트워크 (Wireless Sensor Networks : WSNs)에서 공유키 설정과 브로드캐스트 메시지 인증과정에 적합하지 않다. 지금까지 공개키 암호 시스템 특히 타원곡선 암호 (Elliptic Curve Cryptography : ECC)를 센서네트워크에 적용하는 것에 관한 많은 연구가 진행되어 왔다. 이러한 연구들은 타원곡선 암호 시스템을 실제로 구현하여 동작시간과 코드 크기에 관한 성능을 제시함으로써 센서 네트워크에 타원곡선 암호를 적용하는 것은 가능하다고 결론지었다[1, 8, 10, 15]. 지금까지 상대적으로 만족할만한 성능을 제시한 타원곡선 암호 구현들은 모두 GF(p)에 기반을 두었다 [1, 8, 15]. 반면, 顷(2勺에 기반을 둔 구현들은 센서 네트워크에 적용할 만큼 충분한 성능을 제시하지 못하였다 [4, 7, 9, 10], 몇몇 논문에서 顷(2勺상에서의 유한체 곱셈이 작은 워드 크기를 사용하는 저전력 마이크로프로세서에 의해 효율적으로 지원되지 않기 때문에 센서 모트에서 齐(牙“) 에 기반을 둔 타원곡선의 소프트웨어 구현은 비효율적이라고 주장하였다[1, 8, 10, 15]. 본 논문에서는 이러한 주장을 재검증해보고 실제로 GF©7")상에서의 유한체 곱셈이 顷3)상의 곱셈보다 더 빠를 수 있음을 제시한다. 현재 센서 모트에서 顷(2税 ) 에 기반을 둔 타원곡선의 소프트웨어 구현에 관한 다음과 같은 오해가 있다. 첫째, 비효율적인 유한체 곱셈 : 타원곡선 암호연산 중에서 가장 빈번히 계산되는 연산은 유한체 곱셈과 감산 연산이다. 작은 크기의 워드를 사용하는 저전력 마이크로포로세서에서 6列弈)상의 유한체 곱셈은 partial XOR 곱셈을 요구하기 때문에 GS)상의 유한체 곱셈에 비하여 비효율적인 것으로 인식되고 있다D. 실제로 현재의 저전력 마이크로프로세서들은 paritial XOR 곱셈을 명령어 레벨에서 제공하지 않고 있다.

둘째, ECDSA 구현에 따른 과중한 메모리 소모량 : 6归(2皿)에 기반을 둔 ECDSA 구현은 전자 서명의 생성과 검증을 위하여 宵(方 )상의 유한체 연산 뿐만 아니라 GS) 상의 유한체 연산도 필요로 한다. 따라서 GFiD 상에서의 ECDSA 구현은 G疔8)상에서의 ECDSA 구현보다 많은 양의 코드를 요구한다고 생각될 수 있다. 실제로 센서모트에서 (汐(2队)상의 타원곡선 구현은 대부분 Elliptic Curve Diffie-Hellman (ECDH)만 제공하고 있다. 하지만 顷(若)상에서 최적화된 ECDSA 구현의 코드 크기는 G◎ 상에 기반을 둔 ECDSA의 코드 크기와 견줄만하다. 본 논문에서 제안하는 TinyECCK는 최적화된 ECDSA 구현으로서 현재 센서 모트에서 가장 효율적인 타원곡선 암호의 소프트웨어 구현으로 알려진 TinyECC보다 더 적은 코드 크기를 이용하여 더 빠른 연산을 제공한다.

본 논문의 기여는 다음과 같다.

첫째, 6㎛2勺상에서의 유한체 곱셈이 顷3)상의 유한체 곱셈보다 빠를 수 있음을 보인다 : 如2勺상의 유한체 곱셈과 감산 연산은 많은 수의 메모리 접근 연산 (LOAD와 STORE 명령)을 필요로 한다. 본 논문에서는 유한체 곱셈과 감산과정에서 불필요하게 중복된 메모리접근 명령의 수를 줄일 수 있는 방법을 제시한다. 제안하는 방법을 통하여 6『(2】时)에서의 유한체 곱셈과 감산에 대한 연산 시간을 각각 21.1%와 24.7% 절약할 수 있다. 이때, 제안된 유한체 곱셈은 sectl60rl상에서 최적화된 유한체 곱셈보다 7.4% 빠르다.

둘째, 현재까지 顷(勢)에 기반을 둔 타원곡선의 소프트웨어 구현 중에서 가장 뛰어난 성능을 제공한다. : TinyECCK는 기존의 財(『)상에서 구현된 모든 타원곡선 소프트웨어들의 성능을 능가한다. 뿐만 아니라 GS)의 타원 곡선 암호 구현을 포함하여 ATmegal28 프로세서에서 C언어 또는 C언어와 inline assembly를 혼합하여 구현한 것들에 비하여 더욱 빠르다.

셋째, TinyECCK는 Koblitz 커브상에서 타원곡선 암호 연산을 구현하였다. Koblitz 커브에서 두 배 연산은 간단한 유한체 제곱연산들로 대체될 수 있기 때문에 일반적인 커브에 비하여 더욱 빠른 연산을 제공한다.

Ⅱ. 관련 연구

지금까지 센서모트 상에서 GF(2m)4 GGS)에 기반을 둔 여러 타원곡선 암호 소프트웨어가 구현되었다. 이러한 구현들은 센서 네트워크에서 타원곡선 암호의 실행 가능성을 검증하기 위하여 개발되었다.

2.1 GF(2^m)에 기반을 둔 소프트웨어 구현들

Malan 외는 8 비트 센서 모트에서 顷(若)에 기반을 둔 첫 번째 구현인 EccM을 개발하였다. 그들은 UC Berkeley에서 개발된 TinySec[2] 암호 모듈에 키 분배메커니즘을 제공하기 위하여 타원곡선 암호를 이용하였다[4]. EccM의 코드 크기는 34, 342 바이트이며 하나의 공개키를 생성하는데 34초가 걸린다. Yan과 shi는 센서모트와 같은 작은 임베디드 장치에서 効(毅)에 기반을 둔 타원곡선 암호의 소프트웨어 구현은 여전히 느리다고 지적하였으며, 8 비트 ATmegal28 프로세서에서 6冽2临)상의 빠른 모듈러 감산을 적용한 타원곡선 암호를 구현하였다[9]. Yan과 shi가 구현한 코드 크기는 11, 592 바이트이며 한 번의 스칼라 곱셈을 계산하는데 13.9초가 걸렸다. Eberle 외는 6农(顷)상에서의 유한체 연산들이 (특히 유한체 곱셈) 저전력 마이크로프로세서에 의해서 효율적으로 지원되지 않기 때문에 매우 느리다고 지적하였다[10]. 또한 이들은 명령어 집합 확장 (Instruction Set Extension)을 이용하는 추가적인 아키텍처 확장을 통하여 6貯(勢)상의 타원곡선 연산이 GF{p) 상에서의 연산 보다 빨라질 수 있다고 주장하였다. 실제로 顷(아63)상에서 스칼라 곱셈을 어셈블리 언어로 구현한 결과 4.14 초가 걸렸지만 아키텍처 확장을 이용한 경우 0.29 초 만이 걸렸다. 이 결과는 麥(2勺상의 타원곡선 암호를 저전력 프로세서 상에서 구현할 때 소프트웨어로 구현하는 것보다는 하드웨어로 구현하는 것이 더욱 바람직하다는 주장을 뒷받침해준다. BlaB와 Zitterbart는 6^(2113) 위에서 ECDH, ECDSA 그리고 El.Gamal를 구현하고 이것들의 성능을 EccM과 비교하였다[7]. 이들의 구현은 서명을 생성할 때와 검증할 때 각각 6.88초와 24.17초가 걸리며 코드의 크기는 75, 088 바이트였다.

2.2 GF(p)에 기반을 둔 소프트웨어 구현들

Gura 외는 센서네트워크에서 공개키 암호 시스템의 적용 가능성을 증명하기 위하여 8 비트 ATmegal28 프로세서 상에서 어셈블리 코드와 명령어 집합 확장을 이용하여 RSA와 以3)상의 타원곡선 암호를 구현하였으며 구현된 RSA와 타원곡선 암호의 성능을 비교하였다[15]. 구현된 타원곡선 암호는 한 번의 스칼라 곱셈을 계산하는데 0.81 초 걸리며 이것은 센서 네트워크에서 타원곡선 암호의 사용가능성을 뒷받침 한다. 그들은 또한 유한체 곱셈 연산중에 메모리 접근 명령의 수를 줄이기 위하여 오퍼랜드 곱셈 방식과 프로덕트 곱셈 빙식의 장점을 결합한 혼합 곱셈 알고리즘 (Hybrid multiplication 시gorithm)을 제안하였다. Liu 외가 개발한 TinyECC[l]는 TinyOS[16] 상에서 동작하는 타원곡선암호의 소프트웨어 패키지로서 W(p)상에 기반을 둔 스칼라 곱셈 및 ECDSA 연산의 기능을 제공한다. TinyECC는 효율적인 연산을 위하여 pseudo-Mersenne prime을 이용하는 최적화된 모듈로 감산, 슬라이딩 윈도우 스칼라 곱셈, Jacobian 좌표계, 그리고 혼합 곱셈/ 제곱 알고■리즘을 적용하였다. 유한체 곱셈, 제곱, 감산과 같은 성능의 핵심 부분을 인라인 어셈블리로 구현하여 하나의 서명을 생성하고 검증하는데 각각 2초와 2.43초가 걸리며 이때의 코드 크기는 19, 308 바이트였다. C언어로 구현된 TinyECC는 15, 872 바이트의 줄어든 코드가 사용되지만 서명을 생성하고 검증하는데 6.26초와 7.92초가 소모된다. 지금까지 8 비트 워드 크기를 사용하는 저전력 장치에서 소프트웨어로 구현된 타원곡선 암호 시스템의 성능은 成3)상에 기반을 둔 것들이 顷(2“)상에 기반을 둔 것들보다 더욱 뛰어난 성능을 보였다.

이러한 기존의 결과들을 보면 저전력 장치에서 GF(p) 위의 타원곡선 암호의 소프트웨어 구현이 効(牙〃)에서의 것보다 더욱 효율적인 것으로 보이며, 以(若)의 사용은 하드웨어적으로 구현될 때만 적합한 것으로 보인다. 하지만 본 논문에서는 8 비트 센서 모트 상에서 GF") 상의 최적화된 타원곡선 암호 소프트웨어 구현 (Tiny ECCK)의 성능이 顷3)에서 최적화된 구현 (TinyECC) 의 성능보다 더욱 뛰어날 수 있음을 보인다.

Ⅲ. 타원곡선 암호 시스템의 개요

아래의 유한체 F상에서 정의되는 weierstrass 식을 만족하는 해의 집합은 항등원 역할을 하는 무한원점 (Point at infinity) 과 함께 아벨군을 형성한다.

#

戶의 지표가 2인 경우, 위의 식은 아래와 같이 단순화될 수 있다.

#

아벨군의 규칙에 의거하여 타원곡선 상에 존재하는 두 점 4과 "의 합의 결과 与은 여전히 타원곡선 위에 존재한다. 서로 다른 두 점을 더하는 연산은 타 원곡선점 덧셈 연산 (Elliptic curve point addition : ECADD) 이라고 불리고 같은 점을 더하는 연산은 타원곡선 점두배 연산 (Elliptic curve point doubling : ECDBL)으로 불린다. 곡선상의 임의의 두 점을 각각 0 =(%必), 乃 = 饥2, 洗)라 할 때 (0 宀弓), 4과 %의 합의 결과인 乌의 아핀 좌표는 아래와 같이 계산될 수 있다.

#

아핀 좌표계에서 ECADD와 ECDBLe 각각 1 번의 유한체 역원연산과 두 번의 유한체 곱셈연산을 필요로한다. 역원연산이 곱셈연산에 비하여 막대한 부하를 가져올 경우 사영 좌표계를 사용하는 것이 유리하다. 예를 들어, L6pez-Dahab (LD) 사영 좌표계에서 ECADD와 ECDBLe 각각 14번의 곱셈과 4번의 곱셈을 요구한다2) 따라서 구현 환경에서 I > 7M (I = 역원, M = 곱셈) 인 경우에 LD 좌표계를 사용하는 것이 더욱 효율적이다. 咨(酔)상에서 하나의 점 P를 연속하여 肉번 더하는 것을 스칼라 곱셈 (scalar multiplication)이라고 부르며, Q= kP로 표현된다. 이 스칼라 곱셈은 ECDH와 ECDSA 연산에서 핵심이 되는 계산이다.

Ⅳ. 구현 세부 사항

8 비트 ATmegal28 프로세서를 기반으로 하는 Micaz [14] 센서모트에서 TinyECCK를 구현하였다. Tiny ECCK를 구현하기 위하여 권고된 도메인 파라미터인 sectl63kl [3]를 이용하였으며, 6归(2血)상의 원소를 표현하기 위하여 다항식 기저를 사용하였다. 본 절에서 기술된 알고리즘들은 Guide to Elliptic Curve Cryptography[5, 6] 에 제시된 32 비트 기반의 GF(2m) 유한체 연산 알고리즘들에 기반을 둔 것으로서 8 비트 환경에 맞게 수정하였다. 연산의 효율성을 위하여 TinyECCK에 wNAF, wTNAF 리코딩 알고리즘을 적용하였으며 혼합좌표계[12]를 이용하여 ECADD, ECDBL 연산을 하도록 구현하였다. 구현환경은 TinyOS l.l.lOJan 상에서 NesC를 이용하였다. 또한 컴파일 시 에 optimization level을 2로 설정하였다. 공평한 비교를 위하여 optimization level 2로 컴파일된 TinyECC의 성능과 비교를 행하였다 ([표 6] 참조).

4.1 표기법 정리

刀㊉3: 비트와이즈 XOR.

A&B- 비트와이즈 AND.

亀》兀 상위 비트들을 0으로 패딩하면서 4를 오른쪽으로 i 비트만큼 이동시킨다.

A<i : 하위 비트들을 0으로 패딩하면서 辺를 왼쪽으로 i 비트만큼 이동시킨다.

甲: 하나의 8 비트 워드.

。( 闹 : ( 归》4)를 반환한다.

L(W) : (H&OW70를 반환한다.

扇는 다항식 ▲의 顶번째 워드를 가리킨다.

』{顶}는 다항식 4의 顶번째 워드부터 侃번째 최상위 워드까지를 가리킨다,

(仙认…, *+L4LD 瑚2…3}는 다항식』의, 번째 워드부터 顶번째 워드까지를 가리킨다, 。4[顶], ."4[/+니14同), j>i.

七=「m/帝] 는 다항식 를 메모리에 저장하기 위해 필요한 워드의 개수이다.

ATmegal28 프로세서가 8 비트 워드의 메모리 주소로 동작하기 때문에 알고리즘에서 워드의 크기를 8 비트로 가정한다. 다음 표기법들은 본 논문에서 알고리즘 기술 시에 사용된다. A와 B는 6疔(2叫의 원소라고 가정한다.

4.2 GF(2m)상에서의 유한체 연산

4.2.1 유한체 제곱 연산

顷(2如)의한 원소 业) = %「1严7+... + 瞄2+¥ + %를 제곱하는 것은 a(z)의 이진 표현의 연속한 두 비트 사이에 0을 삽입하여 결과적으로 Q(z)2 = 褊_1扣7 + … + o宓4+(知/+%이 된다. 따라서 사전계산을 통한 table look叩을 통하여 효율적으로 계산할 수 있다分. Algorithm 1은 하나의 워드를 제곱하여 두 워드로 확장한다. 상위 4 비트와 하위 4 비트의 흘수 위치에 0을 삽입하여 각각 8 비트 워드가 생성된다.

#

Algorithm 1. Polynomial squaring

4.2.2 유한체 곱셈 연산

유한체 곱셈은 스칼라 곱셈 연산 중에 계산되는 가장 빈번한 연산중의 하나이기 때문에 효율적으로 구현되어야 한다. 비록 shift-and-add 방법이 직관적이지만 많은 양의 메모리 접근과 워드 shift 때문에 소프트웨어 구현에서는 바람직하지 않다. 실험을 통하여 shift-and- add, right-to-left comb 방법에 비하여 윈도우 기법을 적용한 left-to-ri아it comb 방법이 8 비트 Atmegal28 프로세서에서 더욱 효율적인 것을 알아낼 수 있었다4). 이때 최적의 윈도우 크기는 4였다. 비록 크기 4의 윈도우는 15개의 구성요소에 대하여 사전계산을 해야 하지만 (0 번째 요소는 제외), 이를 통하여 유한체 곱셈의 연산은 현저히 빨라질 수 있다. Algorithm 2는 8 비트 워드 크기를 사용하는 환경에서 윈도우 기법 (糾 = 4)을 적용한 left-to-right comb 방법을 기술하고 있다. 워드 크기가

#

Algorithm 2. Left-to-right comb method using window width w = 4

8 비트이고 윈도우의 크기가 4이기 때문에, u<-U(alj]') 와 는 ”J(a[j]》4), 戒歹)와 같이 효율적으로 계산될 수 있다. Algorithm 2의 과정 6 과 10의 partial XOR 곱셈인 (为}㊉7;는 실제로 for- loop로 구현된다. 즉, 6。}㊉皿의 실제 코드는 “forG = 0;2WE++) g + 顶〕jCE + j']㊉70];"이다' (LOAD 된 g+顶]와 Tu[i] 값에 대하여 XOR연산이 수행된 후 다시 (无+ 顶]에 STORE된다). 따라서 워드의 크기가 작아질수록 더 많은 수의 메모리 접근 명령이 필요하다. 예를 들어 世(2®) 상에서 归=32와 归=8인 경우 각각의 LOAD와 STORE 명령어를 비교해보자. W=32 의 경우는「163/32〕=6이기 때문에 14번의 LOAD와 7번의 STORE 연산을 필요로 하는 반면 归=8인 경우는 「163/8] =21이므로 44번의 LOAD와 22번의 STORE 연산을 요구한다.

4.2.3 모듈러 감산

GW, ")상의 곱셈과 제곱의 결과는 기약다항식 f로감산된다. FIPS 186-2 표준에서 NIST가 권고한 빠른 모듈로 감산을 위한 감산 다항식이 존재한다[3]. 이러한 다항식들은 3차항 (Trinomial) 또는 5차항 (Pen- tanomial) 이기 때문에 c(z)mod/는 효율적으로 계산될 수 있다. Algorithm 3은 곱셈과 제곱의 결과를 顷(2也 ) 의 원소로 감산시킨다. 앞에서 언급한 유한체 곱셈 알고리즘과 마찬가지로 Algorithm 3은 8 비트 워드기반이기 때문에 많은 수의 메모리 접근 연산이 연관되어 있다.

#

Algoritiim 3. Fast reduction modulo

4.3 좌표계 선택

8 비트 워드의 ATmegal28에서 G㎛2勺상의 곱셈 연산에 대한 역원 연산의 비율을 계산해 본 결과 24.99 의 결과를 얻었다 (M-. /= 1:24.99). 따라서 스칼라 곱셈 과정에서 가능한 한 역원 연산을 제거하는 것이 성능을 위하여 바람직하다. 따라서 TinyECCK를 구현할 때 아핀 좌표계 대신 L6pez-Dahab (LD)좌표계를 적용하였다. [표 1]은 TinyECCK에서의 적절한 좌표 선택을 뒷받침해준다. ECADD 연산에 관련된 두 개의 점이 서로 다른 좌표계 (R : LD 좌표계, P2 : 핀 좌표계) 로 표현되어 더해지는 것이 두 점이 서로 같은 좌표계로 표현되었을 때보다 더욱 효율적으로 계산될 수 있다[12]. 따라서 사전계산 테이블에 저장되는 점들은 아 핀 좌표계로 표현하였으며, 실제 ECADD와 ECDBL 과정에서는 혼합좌표계를 사용하였다.

[표 1] ATmega128 프로세서에서 GR2'63)상의 유한체 연산들의 계산 시간 비교 (곱셈과 제곱의 시간은 감산 시간까지 포함하고 있으며 모든 시간은 초로 측정되었다.)

4.4 Width-w NAF (Non-Adjacent Form)와 Width-w TNAF(Tau-adic Non-Adjacent Form)

GF骸f 위의한 점 p=(x】)의 역원은 -p=(x, x-顷) 가 된다. 이와 같이 瓦聲(2皿))의 원소의 역원은 적은 비용의 연산으로 계산될 수 있으며, 두 점의 뺄셈은 덧셈과 같은 방법으로 계산될 수 있기 때문에 스칼라 곱셈 과정에서 부호화된 이진 표현 (&= £}&2很 = 1昭施 2 = 0 &w{0, ±1})을 쉽게 적용할 수 있다. Non-adjacent form (NAF)은 모든 부호화된 이진 표현 중에서 최적의 non-zero 밀도 (1/3)를 제공한다. NAF를 이용한 스칼라 곱셈은 I . ECDBL-Y 1/3 ・ ECADD의 연산으로 계산될 수 있다. (비교 : 이진표현을 사용할 경우 I ・ ECDBL + 1/2 ・ 砍狙庭가 필요하다). 만약 추가적인 메모리가 사용 가능하다면 스칼라 北를 한번에 w 비트씩 처리할 수 있는 슬라이딩 윈도우 방법을 적용하여 스칼라 곱셈의 연산 시간을 더욱 줄일 수 있다. s크기의 윈도우를 사용하는 width-w NAF (wNAF)는 2包-개의 사전계산 점들을 담는 사전계산 테이블을 이용하여 l/(w+l) 의 nonzero 밀도를 제공한다. 따라서 wNAF를 적용한 스칼라 곱셈은 I . ECDBL* l/(w+l) . ECADD의 연스! 으로 계산된다. Micaz 센서모트에서는 128 킬로 바이트의 ROM 메모리와 4 킬로 바이트의 RAM 메모리가 사용 가능하기 때문에 Tiny ECCK에 wNAF를 충분히 적용할 수 있었다. Tiny ECCK의 구현은 sectl63kl에 기반을 두었기 때문에 스칼라 곱셈에 width-w tau-adic non-adjacent form (wTNAF)[ll]을 적용할 수 있다. 식 (2)가 q = 0, 1 그리고 6-0 인 경우, Koblitz 커브라고 불리며 이것의 큰 장점은 스칼라 곱셈에서 ECDBL연산을 몇 개의 간단한 유한체 제곱 연산으로 대체시킬 수 있다는 것이다. 따라서 wTNAF를 적용한 스칼라 곱셈은 //(w+1) - ECADD 만으로 계산될 수 있다. 하지만 wTNAF 리코딩 알고리즘은 추가적인 부분감산 함수 (Partial reduction modulo fimction)와 라운딩 오프 (Rounding off)[ll] 프로시져를 필요로 하기 때문에 wTNAF를 구현하는 것은 wNAF에 비하여 더 많은 코드를 요구한다. TinyECCK에 wNAF와 wTNAF를 적용하였을 때 TinyECCK의 코드 크기는 각각 10870 바이트와 13748 바이트였다. 이것은 Micaz 모트의 사용 가능한 ROM 메모리 크기 (128 킬로 바이트)의 단지 8.3%와 10.5% 였다. 실험을 통하여 Micaz모트에서 최적의 윈도우 크기는 4임을 알아냈다.

Ⅴ. 성능 개선을 위한 제안 테크닉들

4. 2절에서 제시한 곱셈 알고리즘과 감산 알고리즘의 성능은 중복된 메모리 접근을 줄임으로써 더욱 향상될 수 있다. 메모리 접근 연산은 알고리즘의 전체 연산 시간에서 많은 비중을 차지하기 때문에 중복된 메모리 접근을 줄임으로써 알고리즘의 성능을 향상시킬 수 있는 것이다.

5.1 유한체 곱셈 과정에서 중복된 메모리 접근을 줄이기 위한 방법

GF(2m) 상에서의 XOR 곱셈 연산은 많은 수의 중복된 메모리 접근 연산과 연관되어있다. 이 때문에 일반적으로 GF(2m) 상에서의 곱셈 연산이 GF(p) 상에서의 곱셈 연산보다 비효율적이다. [그림 1]은 Algorithm 2 의 곱셈 연산의 계산과정을 보이고 있다. 그림에서 홀수 행들은 Algorithm 2의 두 번째 for-loop (과정 9~11)이고 짝수 행들은 첫 번째 foEoop(과정 5~7)이다. 결과적으로 모든 행들은 마지막 결과인 僱 계산하기 위하여 해당 위치에서 서로 XOR된다. (Partial XOR 곱셈). Algorithm 2에서 첫 번째 for-loop의 결과들은 왼쪽으로 윈도우 크기인 迪만큼 쉬프트 되는데 이는 [그림 1] 에서 잘 나타나있다. Algorithm 2의 각 fbi니oop에서 b(z)에 관한 사전계산 테이블에 접근하여 해당 요소를 가져오기 위하여 £((山[)와 研c山1)가 계산된다. 그 후에 테이블에서 해당 값이 로드되고 이는 다시 C와 j 위치에서부터 顶+应위치까지 XOR된다. (再 =/). [그림 1]을살펴보면 Algorithm 2의 XOR 곱셈이 많은 수의 중복된 메모리 접근 연산과 연관되어 있음을 알 수 있다. 다음 예제는 이것을 확인시켜준다 (설명의 간결함을 위하여 두 번째 for-loop과정만을 고려하였다).

#

(그림 1) 윈도우 방법을 적용한 left-to-right comb 방법의 계산 과정

q, q, q의 계산은 각각 두 번, 세 번, 네 번의 store 명령이 연관되었으며 이것은 중복된 것이다. 또한 각 과정에서 q의 값이 /+1번 LOAD되고 있음을 알 수 있다. (/£ 2。까지, 20<i <41 범위에서는 q 값이 42— 令번 LOAD된다). 따라서 Algorithm 2의 성능은 중복된 STORE 연산의 수와 q의 LOAD 횟수를 줄임으로써 향상될 수 있다. 제안하는 방법은 몇 개의 연속한 XOR 곱셈을 하나로 합침으로써 XOR 곱셈 (<为}㊉九)에 연관된 STORE와 LOAD 연산의 수를 줄이는 것이다?

예를 들어, 。아。膈이)과。1临%5은 “。(1) —Gi} ㊉ 4仙이) (3) …j} ㊉以加 ])…, 이, a이《- a이㊉乌(M비) [이, (心「+1]—。即+1@%"]])四” 로 통합할 수 있다. 이 전략은 Algorithm 4로 일반화된다. 실제로 더 많은 수의 XOR 곱셈을 통합한다면 더 많은 수의 중복 메모리 접근을 줄일 수 있으나 더 많은 양의 코드를 필요로 한다. TinyECCK의 경우에는 코드의 크기를 고려하여 두 개의 연속한 XOR 곱셈을 하나로 통합하였기 때문에 for-loop의 카운터가 2씩 증가한다. Algorithm 4를 이용하여 절약되는 STORE 연산의 수 6) 곱셈과정에서 XOR 곱셈의 수를 줄이는 것이 아니라 XOR 곱셈과정에서 발생하는 중복된 메모리 접근 연산 (STORE 와 LOAD) 의 수를 줄이는 것이다.

예를 들어,。아。膈이）과。1临%5은 “。(1) —Gi} 4仙이） (3)…j} 以加］）…, 이, a이《- a이㊉乌（M비） ［이,（ 「+1］—。即+1@%"］］） ” 로 통합할 수 있다. 이 전략은 Algorithm 4로 일반화된다. 실제로 더 많은 수의 XOR 곱셈을 통합한다면 더 많은 수의 중복 메모리 접근을 줄일 수 있으나 더 많은 양의 코드를 필요로 한다. TinyECCK의 경우에는 코드의 크기를 고려하여 두 개의 연속한 XOR 곱셈을 하나로 통 합하였기 때문에 for-loop의 카운터가 2씩 증가한다. Algorithm 4를 이용하여 절약되는 STORE 연산의 수를 계산할 수 있다. Algorithm 2에서는 for-loop의 카운터가 0에서부터 Z-1까지 증가하며 또한 6(顶}£7;도 fdi니oop이기 때문에 첫 번째와 두 번째 for-loop 과정에서 필요한 STORE 연산의 수는 2砂+4£이 된다. Algorithml 4의 STORE 명령의 수를 계산하면 t2 + 3t + 2 가 된다. 따라서 尹+ —2만큼의 STORE 연산이 절약된 匸土 또한 LOAD 연산의 경우 Algorithm 2는 坦?+6t 번의 LOAD 연산이 연관된 반면 Algorithm 4는 3t2+5t + 2번의 LOAD 연산을 사용한다. 따라서 약 t2+t-2 만큼의 LOAD 연산을 절약할 수 있다. [표 2]를 통하여 Algorithm 4가 Algorithm 2에 비하여 으扌 21.1% 빨라진 것을 확인할 수 있匸+. 또한 Z = 21일 때, Algorithm 4가 Algorithm 2에 비하여 460번의 LOAD와 STORE 연산을 절약하는 것을 확인할 수 있다.

#

Algorithm 4. Proposed left-to-right comb method using window width w=4

(표 2) 제안 방법과 기본의 방법의 성능 비교 (제안 방법을 통하여 절약되는 메모리 접근 연산의 수를 제시하기 위하여 각 알고리즘의 for-loop안에서의 연산수를 계산하여 비교하였다. 모든 시간은 초로 측정되었다.)

5.2 모듈러 감산 과정에서 중복된 메모리 접균을 줄이기 위한 방법

Algorithm 3 역시 중복된 메모리 접근 명령과 관련되어 있다. Algorithm 3의 동작 과정에서 카운터 必" 30에서 27로 감소하는 경우를 살펴보자. 카운터 今가 30 에서 27일 동안 연산 과정은 아래와 같다.

#

Algorithm 3은 이, Gf29], C(28], 기을 계산하기 위하여 16번의 LOAD와 STORE 명령을 사용한다. 하지만 위와 같이 중복된 LOAD와 STORE 명령을 제거하기 위하여 같은 곳에 저장되는 중간 값들을 함께 XOR시켜 한 번에 저장하는 전략을 사용할 수 있다. 이 전략을 적용하여 아래와 같이 계산할 수 있다.

#

#

(표 3) 제안한 방법을 TinyECCK에 적용하였을 때의 향상된 성능 (TinyECCK는 sect163k1 을 이용하였고, 알고리즘 2와 3을 적용하였을 때와 알고리즘 5, 6을 적용하였을 때의 수행 시간을 비교하였다. 모든 시간은 초로 측정되었다.)

Algorithm 5. Proposed fast reduction modulo

위와 같이 LOAD와 STORE 명령의 빈도를 16번에서 10번으로 줄일 수 있다. Algorithm 3은 foi니oop안에서 20 - 4 = 80번의 LOAD와 STORE 명령을 사용한다. 이에 반하여 제안한 기법은 5 ・ 10 = 50번의 LOAD와 STORE 명령만을 이용하여 30번의 LOAD와 STORE 명령을 줄일 수 있다. 이 전략을 일반화한 것이 Algorithm 5이며, 이곳에서는 4번의 fb「loop의 실행을 하나로 통합하였다. [표 2]가 제시한 것처럼 Algorithm 5은 Algorithm 3보다 약 24.7% 빠르게 감산 연산을 수행한다. 더 많은 foi니。。p의 실행을 통합하며 더 많은 수의 메모리 접근 명령의 수를 줄일 수 있지만, 코드의 크기가 증가한다는 단점이 있다. 따라서 최적의 통합 정도를 찾는 것이 필요하다. 실험을 통하여 4번의 for-loop 실행을 통합하는 것이 메모리와 성능을 고려할 때 최적인 것을 알아냈다. [표 3]은 5. 1절과 5. 2절에서 제안한 방법을 TinyECCK를 구현하는데 적용한 결과, 향상된 성능을 제시하고 있다. Algorithm 4와 6를 적용하여 ECDSA 의 sign과 verity의 연산 시간을 약 15~19% 정도 단축시킬 수 있었다. wTNAF를 사용하였을 때보다 wNAF 를 이용하였을 때의 성능향상이 큰 것을 확인할 수 있는데 이것은 wTNAF에서는 ECDBL 연산이 몇 개의 유한체 제곱 연산으로 대체되기 때문이다.

Ⅵ. 실험적인 결과와 분석

본 절에서는 TinyECCK의 성능을 동작 시간, 메모리사용량 및 지원하는 서비스 측면에서 분석하고, 센서 모트 상에서 기존의 소프트웨어 구현들과 성능을 비교한다.

6.1 유한체 연산의 분석

센서모트 상에서 GF(2m) 위의 유한체 곱셈의 성능이 GF(p) 상의 곱셈의 성능보다 빠를 수 있음을 보이기 위하여 TinyECCK와 TinyECCR]를 비교한다. Tiny ECC 는 불필요한 메모리 접근을 줄이기 위하여 추가적인 레지스터를 사용하는 혼합 곱셈/제곱 방법 (hybrid multiplication/squaring)과 pseudo-Mersenne prime을 사용하는 최적화된 모듈로 감산을 적용하였기 때문에 윈도우를 사용하는 left-to-right comb 방법 (Algorithm 4) 과 빠른 감산 연산 (Algorithm 5)을 적용한 TinyECCK 와 비교하는 것은 적당하다. [표 4]는 TinyECCK의 곱셈 연산이 TinyECC의 곱셈 연산보다더 빠름을 보여 준다 (곱셈 연산과 제곱 연산의 시간은 감산 연산의 시간까지 포함하고 있다). 실제로 TinyECCK의 곱셈 연산이 Algorithm 2를 이용하였을 때는 TinyECC의 곱셈 연산보다 느렸으나 Algorithm 4를 적용하여 TinyECC의 곱셈 연산보다 더욱 빨라질 수 있었다 ([표 2] 참조). TinyECCK의 역원 연산이 TinyECC의 역원 연산보다 더 빠른 점을 차치하더라도 TinyECCK의 제곱 연산은 TinyECC에서의 연산보다 더욱 효율적으로 계산된다.

(표 4) TinyECCK와 TinyECC의 유한체 연산의 비교 (공평한 비교를 위하여, (, 버전의 TinyECC와 비교하였으며 모든 시간은 초로 측정되었다.)

6.2 TinyECCK와 TinyECC의 코드 크기 비교

TinyECCK가 스칼라 곱셈 연산과 ECDSA 서비스를 지원하기 위하여 6农(弈)과 GGS)에서의 연산을 구현하였음에도 불구하고 TinyECC보다 더 작은 코드 크기를 사용한다. [표 5]는 동등한 연산을 하였을 때 TinyECCK와 TinyECC의 계산시간과 코드 크기를 비교한다. 비록 C로만 구현한 TinyECC의 경우 Tiny ECCK와 비교하여 코드 크기가 조금 더 크고, 성능은 현저히 떨어졌다. 계산 시간을 단축시키기 위하여 곱셈/ 제곱, 감산 등 성능의 핵심 부분을 inline assembly로 구현하였으나 TinyECCK와 비교하여 코드 크기와 계산 시간 측면에서 뒤떨어진다. 스칼라 곱셈과 ECDSA 연산에서 TinyECCK의 코드 크기가 C로 구현된 Tiny

(표 5) TinyECCK와 TinyECC의 성능 및 코드 크기 비교 (시간과 코드 크기는 각각 초와 바이트로 측정되었다.)

ECC보다 더 작을 뿐만 아니라 계산 시간 측면에서도 inline assembly를 이용한 TinyECC보다 더욱 뛰어났다. [표 5]를 통하여 TinyECCK가 TinyECC와 비교하여 성능과 코드 크기에서 더욱 효율적임을 알 수 있다. TinyECCK가 TinyECC와 비교하여 코드의 크기가 더 작을 수 있는 가장 큰 이유는 C로만 구현하였음에도 불구하고 assembly나 inline assembly로 구현된 것들보다 뛰어난 성능을 제공하기 때문이다. 이 결과를 통하여 做(必)에서 최적화된 ECDSA구현의 코드 크기는 GF(p) 상의 ECDSA구현의 코드 크기보다 더 작을 수 있다는 것을 확인할 수 있다.

6.3 기존의 구현들과 성능 비교

[표 6]은 지금까지 센서 모트 상에서 구현된 타원곡선 암호 소프트웨어들의 성능을 계산 시간, 코드 크기, 지원하는 프로토콜 등의 측면에서 TinyECCK와 비교하고 있다. 기존의 GW1")상의 구현들[4, 7, 9, 1이의 성능이 做3)상에서 구현된 것들[1, 8] 보다 뒤떨어지는 것을 확인할 수 있다. 비록 [1 이에서는 타원곡선 암호를 완전히 어셈블리언어로 구현 하였지만 핵심 부분에만 인라인 어셈블리언어를 사용한 TinyECC[l]에 비하여 그 성능이 뒤쳐진다. [4], [9]는 도메인 파라미터로 sectl63kl을 사용하였지만 스칼라 곱셈 과정에 TNAF 방법을 구현하지 않았기 때문에 Koblitz 커브의 장점을 충분히 활용하지 못하였다. 어셈블리 언어로 구현된 [1 이보다 C언어로만 구현된 TinyECCK의 성능이 더 뛰어난 이유는 TinyECCK에 Algorithm 4와 6 그리고 wTNAF 기반의 스칼라 곱셈이 적용되었기 때문이다. 표에서 확인할 수 있듯이 TinyECCK는 동작 시간, 사용된 ROM, RAM의 크기 측면에서 기존의 구현들에 비하여 우수한 성능을 제공한다. TinyECCK에서 스칼라 곱셈을 계산하는 모듈의 코드 크기는 5, 592 바이트이며 2TNAF와 4TNAF가 적용될 때 각각 330 바이트와 618 바이트의 RAM을요구한다. 더욱이 이것의 성능은 지금까지 C 또는 C와 inline assembly를 이용하여 구현된 타원곡선의 소프트웨어 구현 중에서 가장 뛰어나다. 비록 서명 생성, 검증 등의 추가적인 구현으로 TinyECCK의 ECDSA 모듈의 코드 크기는 13, 748 바이트로 증가하였지만 여전히 19, 308 바이트를 이용하는 TinyECCK 비교하여 더 적은 메모리를 사용한다. 뿐만 아니라 TinyECCK는 TinyECC와 비교하여 사전계산 테이블과 도메인 파라미터를 초기화하는데 더욱 적은 시간을 소비한다. TinyECCK에 4TNAF가 적용되었을 때 사전 계산 테이블을 구성하는데 0.2515 초가 걸린 반면, TinyECC는 4-ary window 방법의 사전 계산 테이블을 초기화하는데 L83 초가 걸렸다. TinyECCK 를 이용하여 두 센서 모트는 1.14 초 안에 공통키를 계산할 수 있으며, 또한 137 초와 2.32 초 안에 각각 하나의 서명을 생성하고 검증할 수 있다. 지원하는 프로토콜 측면에서, TinyECCK는 传(2勺상의 모든 타원곡선연산 (ECADD, ECDBL, 스칼라 곱셈)을 제공하며 ECDSA의 서비스도 제공한다.

(표 6) 센서 모트 상에서 구현된 타원곡선 암호 소프트웨어들의 성능 비교 (w 는 사용된 윈도우의 크기를 의미하며 init 은 사전계산 테이블을 구성하는데 걸린 시간이다. 모든 시간은 초로 측정되었다)

Ⅶ. 결론 및 향후 연구

본 논문에서는 GF") 상에서의 곱셈, 감산 연산의 비효율성이 중복된 메모리 접근에 기인한다는 것을 보였으며 이러한 불필요한 메모리 접근을 줄일 수 있는 방법을 제시하였다. 제안 방법을 통하여 方(以63) 상에서의 곱셈 연산과 감산 연산의 계산 시간을 각각 21.1%, 24.7%만큼 절약할 수 있었다 제안된 곱셈과 감산 연산을 통하여 ECDSA의 sign과 verify의 계산 시간을 15~19%정도 줄일 수 있었다. 뿐만 아니라 이때의 향상된 곱셈 연산의 성능은 sectl60rl상에서 혼합 곱셈 7) 2007년 11월 2일자로 TinyECC의 버전이 0.3에서 1.0으로 업데이트 되었다. 1.0에서는 추가적으로 ECDH, ECIES 프로토콜을 지원한다. 표 6에서 TinyECCK와의 비교를 위하여 TinyECC의 ECDSA 모듈의 성능과 메모리 사용량을 이용하였음을 밝힌다.

알고리즘을 이용하여 최적화된 연산보다 7.4% 빠르다. 제안된 방법을 이용하여 Micaz 센서 모트에서 동작하는 타원곡선 암호 라이브러리인 TinyECCK를 개발하였으며 센서 모트 상에서 구현된 기존의 타원곡선 암호 소프트웨어들과 그 성능을 비교하였다. 연산 시간, 코드 크기, 지 원하는 프로토콜 측면에서 Tiny ECCK의 성능이 기존의 것들보다 더욱 우수함을 알 수 있었다. 이러한 실험결과와 분석을 통하여 다음 두 가지의 결론을 얻을 수 있었다. 첫 번째, 작은 크기의 워드를 사용하는 저전력 장치에서 GF") 상의 타원곡선 암호의 소프트웨어 구현이 비효율적이라는 기존의 생각과는 달리 麥(2”)상에서 타원곡선 암호 소프트웨어를 구현하는 것이 或3)에 비하여 더욱 적당하다. 세심한 구현을 통하여 6农(欢)상의 곱셈 연산이 6农(μ)에서의 곱셈 연산보다 더 빠를 수 있었다. 두 번째는, 센서 네트워크를 안전하게 만들기 위해서 타원곡선 암호, 특히 TinyECCK의 사용은 충분히 가능하다는 것이다.

향후 연구로는 8 비트 Micaz 센서 모트에서 개발한 TinyECCK를 16 비트 환경의 telosB[17] 모트에 이식하는 것이다. 8 비트 워드를 기본으로 하여 구현한 Tiny ECCK와 16 비트 워드로 변환하여 구현한 TinyECCK 를 각각 telosB 모트에 이식하여 그 성능을 비교할 것이다. 또한 telosB 모트에서 동작하는 TinyECCK의 성능을 기존에 telosB 모트에서 구현된 타원곡선 암호 소프트웨어와 비교할 것이다.