KR20180104585A

KR20180104585A - 보안모듈을 이용한 교통카드 발급 및 운용 시스템 및 방법

Info

Publication number: KR20180104585A
Application number: KR1020180057872A
Authority: KR
Inventors: 김승훈
Original assignee: 김승훈
Priority date: 2018-05-21
Filing date: 2018-05-21
Publication date: 2018-09-21

Abstract

본 발명은 별도의 단말에 의해서 사용자ID를 포함하는 데이터를 기초로 교통 카드 발급요청에 의해서 교통카드를 발급하는 시스템 및 방법에 관한 것으로 상기 발급 과정을 제어하는 발급부; 상기 발급부와 연결되어 있고, 발급할 교통카드에 부여된 카드ID가 저장되어 있는 제1저장부; 상기 발급부와 연결되어 있고, 발급할 카드ID에 대응하는 고유키를 생성하여 발급SAM; 상기 발급부는 사용자ID, 카드ID, 고유키를 포함하는 데이터를 보안저장이 필요한 데이터와 보안저장이 필요하지 않은 데이터를 분리하여 서로 다른 저장공간에 저장하고, 상기 카드ID를 포함하는 소정의 데이터를 상기 단말에 전송하는 것을 특징으로 한다.
또한, 본 발명은 상기 발급된 교통카드를 충전 또는 교통카드를 이용하여 비용을 결제하는 시스템 및 방법에 관한 것으로 상기 교통 카드와 연결되어 있고, 충전 정보를 상기 단말과 통신하는 운용부; 상기 운용부와 연결되어 있고, 보안저장이 필요한 데이터 및 보안저장이 필요하지 않은 데이터를 나누어서 저장되어 있는 저장장치를 포함하는 것을 특징으로 한다.

Description

보안모듈을 이용한 교통카드 발급 및 운용 시스템 및 방법{PASS CARD ISSUE AND OPERATING SYSTEM BY USING SECURITY MODULE AND METHOD THEREOF}

본 발명은 교통카드 발급 및 운용 시스템 및 그 방법에 대한 것으로, 특히 보안 모듈을 이용하여 교통카드 발급하고 운용하는 시스템 및 그 방법에 관한 것이다.

대중교통 및 그 연계 할인서비스가 발달함에 따라, 교통카드는 우리 일상에 꼭 필요한 결제수단이다.

제1세대 교통카드는 카드 또는 카드에 준하는 다양한 모양의 물리적 매체에 소정의 금액을 충전해서 사용하는 형태였다. 각각의 교통카드는 카드ID가 존재하고, 그 카드ID를 기준으로 충전, 결제하고, 정산하는 구조였다. 충전 및 결제를 하기 위해서는 교통카드와 결제단말간의 정보교환을 통해서 이루어진다.

정보교환은 카드와 단말의 고유키를 포함한 서명화된 데이터를 이용하여 이루어진다. 즉, 카드를 사용함에 있어서는 상기 고유키가 노출이 되면 절대 안되고, 키가 노출이 되면, 제3자가 카드의 금액을 돈을 지불안하고 충전을 할 수도 있고, 카드안에 금액을 조작할 수도 있는 심각한 문제를 초래한다. 물리적인 카드의 경우에는 카드의 고유키를 카드 발급 시, 카드ID와 함께 카드에 내장을 시킨다.

물리적인 제1세대 교통카드는 들고다녀야 하는 불편함이 있었고, 또한 카드를 잃어버리게 되면, 카드가 무기명카드이기 때문에 돈을 잃어버리는 문제점이 있었다.

제2세대 교통카드는 소위 앱카드의 형식으로 스마트폰의 가상의 교통카드를 발급받고, 충전하여 사용하는 형태이다. 물리적인 카드가 없다는 점에서 굉장히 큰 장점이 있다.

앱카드 역시 고유키를 이용해서 운용이 되고, 고유키는 스마트폰 내의 USIM에 저장이 된다. USIM에 고유키가 저장이 되기 때문에, 스마트폰의 화면을 활성화 시키지 않고도 사용이 가능한 것이다.

하지만, 이러한 경우에도 스마트폰을 잃어버리거나 하면 USIM을 잃어버려서 보안상 취약한 문제가 있고, 중간에서 그 정보를 악용하기가 좋은 구조이다. 그래서 통상 교통카드는 1일 사용액 제한등을 하여, 노출이 되더라도 피해를 최소화 하는 형태로 운용되고 있다.

모든 교통 카드는 크게 두가지의 문제점이 있다.

첫째, 물리적 카드 및 앱카드 모두 분실 시 충전된 잔액이 복구가 힘들다. 앱카드의 경우에는 분실이 아닌 USIM을 변경만 하더라도, 새롭게 카드를 발급받아서(고유키를 USIM에 저장하기 위한 절차) 사용을 해야 한다.

둘째, 고유키를 물리적으로 갖고 다니는 형태이기 때문에 보안에 취약하다는 단점이 있다.

셋째, 앱카드의 경우에는 USIM의 형태, 스마트폰의 기종에 따라서 사용이 가능한 경우가 있고, 사용이 불가능한 경우가 있으며, 제휴사와의 협력 등이 필요해서, 이해관계가 복잡한 경우에는 사용이 굉장히 제한적일 수 있다.

본 발명이 해결하고자 하는 과제는 교통카드를 분실하거나, 스마트폰을 변경하더라도, 교통카드 재구매없이, 종래에 본인이 사용하는 교통카드를 다시 사용할 수 있고, 이 과정에서 고유키의 보안을 높이고, USIM이나 스마트폰, 제휴사의 제약을 없애는 데 그 목적이 있다.

본 발명의 과제를 해결하는 수단으로 별도의 단말에 의해서 사용자ID를 포함하는 데이터를 기초로 교통 카드 발급요청에 의해서 교통카드를 발급하는 시스템은 상기 발급 과정을 제어하는 발급부; 상기 발급부와 연결되어 있고, 발급할 교통카드에 부여된 카드ID가 저장되어 있는 제1저장부; 상기 발급부와 연결되어 있고, 발급할 카드ID에 대응하는 고유키를 생성하여 발급SAM; 상기 발급부는 사용자ID, 카드ID, 고유키를 포함하는 데이터를 보안저장이 필요한 데이터와 보안저장이 필요하지 않은 데이터를 분리하여 서로 다른 저장공간에 저장하고, 상기 카드ID를 포함하는 소정의 데이터를 상기 단말에 전송하는 것을 특징으로 한다.

발급 시스템의 일 실시예에 있어서, 상기 소정의 데이터는 고유키를 포함하지 않는 것을 특징으로 한다.

발급 시스템의 일 실시예에 있어서, 상기 사용자ID, 카드ID, 고유키를 포함하는 데이터는 제1보안모듈에 의해서 보안저장이 필요한 데이터와 보안저장이 필요하지 않은 데이터로 분리되어, 상기 발급부에 제공되고, 상기 발급부는 각각의 데이터를 서로 다른 저장공간에 저장하는 것을 특징으로 한다.

발급 시스템의 일 실시예에 있어서, 상기 서로 다른 저장공간은 제2저장부와 제2보안모듈인 것을 특징으로 한다.

발급 시스템의 일 실시예에 있어서, 상기 발급부는 서버이고, 상기 제1 보안모듈과 제2 보안모듈은 별도의 하드웨어 장치인 것 특징으로 한다.

발급 시스템의 일 실시예에 있어서, 상기 제1저장부와 제2저장부가 하나의 저장공간에서 논리적으로만 나눠져 있는 것을 특징으로 한다.

발급 시스템의 일 실시예에 있어서, 상기 발급부는 서버이고, 상기 제1 보안모듈과 제2 보안모듈은 하나의 장치로 구성하되, 논리적 또는 하드웨어적으로 나눠져 있는 것을 특징으로 한다.

본 발명의 과제를 해결하는 수단으로 교통카드 발급서버를 이용한 교통카드 발급 방법은 상기 교통카드 발급서버는 사용자ID를 포함하는 데이터에 의해서 카드발급 요청을 수신하는 단계; 상기 교통카드 발급서버가 발급할 카드ID에 대응하는 고유키를 생성하는 단계; 상기 교통카드 발급서버가 사용자ID, 카드ID, 고유키를 포함한 데이터를 보안저장이 필요한 데이터와 보안저장이 필요하지 않은 데이터로 분리하는 단계; 상기 보안이 필요한 데이터와 보안이 필요하지 않은 데이터를 서로 다른 저장장치에 저장하는 단계를 포함하는 것을 특징으로 한다.

교통카드 발급 방법의 일 실시예에 있어서, 상기 교통카드 발급서버는 교통발급 요청을 수신단계 후, 발급할 카드ID를 별도의 서버에서 수신 또는 제1저장부에서 읽어오는 단계를 더 포함하는 것을 특징으로 한다.

교통카드 발급 방법의 일 실시예에 있어서,상기 고유키를 생성하는 단계는 상기 발급서버가 카드ID를 포함한 데이터를 교통카드 발급서버와 소정의 통신방식으로 연결되어 있는 발급SAM에 전송하는 단계, 상기 발급SAM는 고유키를 생성하여 상기 발급서버에 전송하는 단계, 상기 발급서버는 상기 고유키를 수신하는 단계를 더 포함하는 것을 특징으로 한다.

교통카드 발급 방법의 일 실시예에 있어서, 상기 데이터를 분리하는 단계는 상기 발급서버가 사용자ID, 카드ID, 고유키를 포함한 데이터를 발급서버와 소정의 통신방식으로 연결되어 있는 제1보안장치에 전송하는 단계, 상기 제1보안장치는 사용자ID, 카드ID, 고유키를 포함한 데이터를 보안저장이 필요한 데이터와 보안저장이 필요하지 않은 데이터로 분리하는 단계, 상기 제1보안장치는 분리된 데이터를 발급서버에 전송하는 단계를 더 포함하는 것을 특징으로 한다.

교통카드 발급 방법의 일 실시예에 있어서, 상기 서로 다른 저장장치에 저장하는 단계는 상기 발급서버는 보안저장이 필요한 데이터는 제2보안장치에 저장하고, 보안저장이 필요하지 않은 데이터는 제2저장장치에 저장하는 단계를 더 포함하는 것을 특징으로 한다.

본 발명의 과제를 해결하기 위한 수단으로 사용자ID, 카드ID를 포함하는 정보가 저장되어 있는 교통 카드를 포함하는 단말를 이용하여, 교통카드를 충전하는 시스템은 상기 교통 카드와 연결되어 있고, 충전 정보를 상기 단말과 통신하는 운용부; 상기 운용부와 연결되어 있고, 보안저장이 필요한 데이터 및 보안저장이 필요하지 않은 데이터를 나누어서 저장되어 있는 저장장치를 포함하는 것을 특징으로 한다.

본 발명의 과제를 해결하기 위한 수단으로 사용자ID, 카드ID를 포함하는 정보가 저장되어 있는 교통 카드를 포함하는 단말를 이용하여, 비용을 결제하는 시스템은 상기 교통 카드와 연결되어 있고, 결제 정보를 상기 단말과 통신하는 운용부; 상기 운용부와 연결되어 있고, 보안저장이 필요한 데이터 및 보안저장이 필요하지 않은 데이터를 나누어서 저장되어 있는 저장장치를 포함하는 것을 특징으로 한다.

본 발명의 효과는 다음과 같다.

첫째, 카드 발급 시, 사용자의 정보를 이용하여 발급함으로써, 카드를 잃어버려도, 스마트폰의 USIM을 바꾸어도, 본인이 사용하던 카드를 그대로 사용할 수 있도록 하는 장점이 있다.

둘째, 고유키를 카드에 저장하지 않고, 별도의 보안장치에 저장을 하기 때문에 카드를 잃어버려도 본인의 고유키를 분실할 걱정이 없다.

도 1 본 발명에서 제안하는 교통카드 발급 시스템의 일 실시예의 개념도
도 2 내지 도 7 본 발명에서 제안하는 교통카드 발급 방법
도 8 본 발명에서 제안하는 교통카드 충전 시스템의 일 실시예의 개념도
도 9 본 발명에서 제안하는 교통카드 충전 방법 흐름도
도 10 본 발명에서 제안하는 교통카드를 이용한 결제 시스템의 일 실시예의 개념도
도 11 본 발명에서 제안하는 교통카드를 이용한 결제 방법 흐름도

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시 예를 가질 수 있는 바, 특정 실시 예들을 도면에 예시하고 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.

제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에서, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서 "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해서 일반적으로 이해되는 것과 동일한 의미를 가지고 있다.

일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하에서, 첨부된 도면들을 참조하여 본 발명에 따른 보안모듈을 이용한 교통카드 발급 및 운용 시스템 및 방법에 대해 상세하게 설명한다.

교통카드 발급 및 운용시스템은 크게 3가지의 기능으로 나뉜다.

교통카드 발급, 교통카드 충전, 교통카드를 이용한 결제(구매)로 나뉜다. 종래에는 발급하는 장치, 충전하는 장치, 결제하는 장치가 각각 구성이 되어 있었고, 발급하는 장치는 교통카드를 발급하여 납품하고, 충전하는 장치는 별도의 장소에서 비치하여 운용하였고, 교통카드 결제는 버스, 택시, 편의점 등에 장치를 두어 운용하였다. 이 같이 운용하는 이유는 발급, 충전, 결제를 하기 위해서는 카드를 구별하기 위한 카드ID와 이에 대응하는 암호화된 서명을 생성시키기 위한 고유키의 보안관리 때문이다.

발급의 경우에는 카드ID에 대응하는 고유키를 생성하는 과정이 필요하다. 고유키는 발급장치와 소정의 통신방식(USB, TCP/IP 등)으로 연결된 발급SAM(Security Access Module)이 이용된다. 발급SAM은 카드형태일 수 있고, 메모리 스틱, 별도 장치의 형태로 구현된다.

발급SAM은 카드ID를 포함한 정보를 기초로, 발급SAM이 갖고 있는 유일키를 이용하여, 발급하고자 하는 고유키를 생성시키고, 고유키를 암호화하고, 서명을 생성하여, 발급장치를 통해서 발급하고자 하는 신규카드에 고유키를 포함한 정보를 저장하고, 저장하는 과정에서 서명을 이용해서 정확한 고유키가 저장이 되었는지 확인을 한다. 이 때, 고유키는 암호화가 될 수도 있고, 안될 수도 있지만 보안성을 높이기 위해서는 고유키를 암호화하는 것이 바람직하다.

발급되는 카드에는 카드ID, 고유키, 잔액, 교통카드가 청소년용인지 일반용인지, 지역, 카드제조정보 등을 포함하는 다양한 데이터가 함께 저장될 수 있다.

충전장치는 발급된 교통카드로부터 카드ID와 고유키를 포함하는 서명정보를 받아서 정상적인 교통카드인지 장치가 정상적인 충전장치인지 서로 식별하는 과정을 거쳐서, 원하는 금액을 충전한다.

결제장치 또한, 발급된 교통카드로부터 카드ID와 고유키를 포함하는 서명정보를 받아서 정상적인 교통카드인지 장치가 정상적인 결제장치인지 서로 식별하는 과정을 거쳐서, 원하는 금액을 결제한다.

종래의 교통카드를 발급하고, 운용하는 방식의 경우에는 고유키와 교통카드를 식별할 수 있는 카드ID(교통카드의 경우에는 무기명)를 기초로 하고 있다. 즉 고유키와 금액정보등은 중요한 정보임에도, 통상 암호화하지 않고 저장을 하고 있다. 그 이유는 통상의 교통카드는 소액이 충전되어 있고, 후불제 카드 또한 금액의 상한이 있기 때문이다.

하지만, 교통카드를 이용하여 결제하는 방식이 교통요금 외에도 편의점 요금 등 다양하게 확장되고 있고, 고유키의 노출, 무기명 카드사용으로 인한 카드 재발급 시 종래 금액 리셋, 카드사의 낙수효과 등이 꾸준히 문제시 되어 왔다. 본 발명은 이러한 문제점을 해결하기 위해, 본 발명을 착안을 하였다.

본 발명의 교통카드는 물리적인 교통카드일 수 있지만, 스마트폰에 내의 앱카드일 수도 있고, 은행앱의 하나의 기능(모듈)로 구현될 수 있다.

요즘의 스마트폰은 사용자의 메일 정보(GMAIL, 아이클라우드)를 이용하여 스마트폰의 앱을 관리하고, 은행앱의 경우에는 개인주민번호가 아닌, 개인에게 부여된 CI번호를 이용하여 은행앱은 사용자를 식별하고 관리한다. 즉 스마트폰 내의 앱카드 또는 은행앱의 하나의 모듈로 구현되는 경우 모두 사용자를 식별할 수 있는 정보를 포함하고 있다.

본 실시예는 은행앱에 하나의 모듈로 구현되는 경우, 실시예로 본 발명을 설명한다. 하지만, 본 실시예는 다양한 형태로 구현되는 교통카드를 모두 포함할 수 있을 것이다.

도 1은 교통카드 발급 시스템(1000)의 개념도이다.

교통카드 발급 시스템(1000)은 별도의 단말(10)의 은행앱의 내장되어 있는 교통카드 모듈에서 교통카드발급을 요청하면, 발급부(100)는 그 요청을 수신한다.

단말과 교통카드 발급 시스템(1000)은 소정의 통신방식에 의해서 통신을 할 수 있고, 소정의 통신방식은 LTE, TCP/IP 등이 이용되어질 수 있다.

상기 단말(10)에서 교통카드 발급을 할 때, 교통카드 모듈(11)이 있는 은행앱은 사용자의 CI정보(은행앱이 아닌 교통카드앱의 경우에는 이메일정보 등)와 같은 사용자ID를 포함한 데이터를 송신할 수 있다. 상기 모듈(11)은 소프트웨어적으로 구성된 모듈이다.

이 때, 전송되는 데이터는 사용자ID 외에도 발급을 원하는 카드의 종류가 청소년용인지 성인용인지와 같은 다양한 옵션에 대한 정보를 포함한다. 상기 발급부(100)는 하드웨어적인 단일 서버로 구현될 수 있고, 서버 내, 그 기능을 소프트웨어적으로 라이브러리화 하여 구성을 할 수 있다. 이 같은 발급부(100)는 발급 서버로 명명할 수 있다.

상기 단말(10)의 요청은 발급부(100)에서 수신을 하면, 발급부는 신규 발급할 교통카드의 카드ID가 저장되어 있는 제1저장부(210)에서 카드ID를 읽어 온다. 카드ID는 카드사 서버(20)에서 발행 시마다 받을 수도 있고, 소정의 규칙에 따라 한번에 다수의 카드ID를 발급받아서 제1저장부(210)에 저장하여 사용할 수 있다. 카드사 서버(20)와 항시 통신이 가능하다는 보장이 없으므로, 바람직하게는 한번에 다수의 카드ID를 발급받아서 운용하는 것이 운용상 편할 것이다.

발급부(100)는 사용자ID에 대응되는 카드ID를 포함한 소정의 정보를 발급SAM(310)에 전송하고, 발급SAM(310)은 내장되어 있는 유일키를 기초로 상기 카드ID에 대응되는 고유키를 생성 또는 저장되어 있는 것을 카드ID에 매칭하여 발급하고, 발급된 고유키는 서명과 함께 발급부(100)로 전송을 한다. 전송될 때, 고유키는 암호화가 될 수도 있고, 안될 수도 있지만 보안 상 암호화를 하는 것이 바람직하다.

상기 발급부(100)는 수신된 고유키와 전자서명 중, 전자서명을 이용하여, 정확히 고유키가 수신되었는지 확인을 한다. 정확히 수신이 되었으면, 고유키, 사용자ID, 카드ID 등 요청된 정보를 포함하여, 보안이 필요한 데이터(DS)와 보안이 필요하지 않은 데이터(DD)를 분리할 수 있다.

그 후, 보안이 필요한 데이터는 암호화를 하고, 보안이 필요하지 않은 데이터는 암호화를 하지 않는다. 암호화를 한 데이터와 암호화를 하지 않은 데이터를 각각 나누어서 생성하고, 두 데이터에 각각 동일한 특정 플레그를 이용해서 인덱싱(DI)한다. 인덱싱한 각각의 데이터는 인덱싱을 이용하여, 분리된 데이터를 하나로 합칠 때, 분리된 데이터를 식별할 수 있다. 또한, 각각의 데이터는 서명을 추가적으로 생성하여, 데이터에 포함시킬 수 있고, 이를 이용하여 데이터가 정확히 송/수신되었는지 확인할 수 있다.

보안이 필요한 데이터는 고유키를 포함하는 고유키, 금액, 거래일련번호 등이 대표적일 것이고, 보안이 필요하지 않은 데이터는 카드ID 등이 대표적일 것이다.

보안이 필요한 데이터와 보안이 필요하지 않은 데이터의 분리는 발급부(100)의 내부에서도 할 수 있지만, 보안성을 높이기 위해서 제1보안모듈(400)을 별도로 구성하여 구현할 수 있다. 상기 제1보안모듈(400)은 별도의 장치로 구성하는 경우에는 TCP/IP, USB를 이용한 통신, PCI 등과 같은 통신 방식으로 연결할 수 있고, 발급부(100)가 서버로 구성되는 경우, 카드 또는 모듈 형태로 꼽아져서 서버 내의 USB 등과 같은 형태로 구성되어 질 수 있다.

별도의 제1보안모듈(400)을 이용하는 경우에는 상기 발급부(100)는 제1보안모듈(400)에 암호화되 고유키, 사용자ID, 카드ID, 다양한 옵션 정보를 포함한 데이터를 서명과 함께 상기 제1보안모듈(400)에 전송한다.

제1보안모듈(400)이 발급부(100)로부터 서명을 포함한 데이터를 수신하면, 암호화되어 있는 고유키를 복호화하고, 이 과정에서 고유키가 정확한지 서명값을 이용하여 확인을 한다.

서명을 이용해서 정확하다고 판단되면, 상기 제1보안모듈(400)은 보안이 필요한 데이터(DS)와 보안이 필요하지 않은 데이터(DD)로 분리를 하고, 보안이 필요한 데이터는 암호화를 할 수 있고, 보안이 필요하지 않은 데이터는 암호화를 하지 않을 수 있다.

만약 암호화를 하면, 암호화를 한 데이터와 암호화를 하지 않은 데이터를 각각 나누어서 생성하고, 두 데이터에 각각 동일한 특정 플레그를 이용해서 인덱싱한다. 인덱싱을 이용하여, 나누어진 데이터는 하나의 데이터로 식별할 수 있다.

상기 인덱싱은 발급부(100)에서 소정의 일련번호를 갖는 값을 순차적 발급하여, 이를 ID로 부여하여 구성할 수 있고, 사용자ID, 카드ID 등을 이용하여 구성할 수도 있다.

또한, 발급부(100)에 분리된 데이터를 보내기 전에, 분리된 데이터는 각각 서명을 포함하여, 서명을 통해서, 정확한 고유키를 수신하였는지 발급부(100)는 확인할 수 있다.

인덱싱된 보안이 필요한 데이터와 보안이 필요하지 않은 데이터는 발급부(100)를 통해서 분리되어 보안이 강화된 저장부와 보안이 특별히 없는 저장부 저장된다. 저장은 발급부(100)의 내부의 저장장치가 될 수도 있고, 별도의 장치에 저장될 수 있다.

바람직하게는 보안이 필요하지 않는 데이터는 제2저장부(220)에 저장하고, 보안이 필요한 데이터는 제2보안모듈(500)에 저장하는 것이다.

상기 제2보안모듈(500)은 앞서 설명한 제1보안모듈(400)과 동일 또는 유사한 형태로 구성할 수 있다. 상기 제1 내지 제2 보안모듈은 HSM(hardware security module)이라 불리는 별도의 장치를 이용하는 것이 보안성 측면에서는 가장 바람직할 것이다. HSM을 사용하게 되면, 슈퍼바이저를 제외하고는 작업자가 보안이 필요한 데이터의 정보도 볼 수 없고, 조작도 할 수 없기 때문이다.

제2보안모듈(500)에는 보안이 필요한 데이터를 저장하고, 만약 암호화되어 있는 경우에는 이를 복호화하는 기능을 포함되고, 서명을 이용하여 고유키가 정확한지 여부를 식별할 수 있는 별도의 인증모듈(510)을 포함할 수 있다. 인증모듈(510)은 서명을 확인도 가능하고, 서명을 생성시킬 수 있는 기능을 포함한다.

상기 발급부(100)는 인덱싱을 포함한 보안이 필요한 데이터와 보안이 필요하지 않은 데이터를 분리하여 저장하고, 상기 교통카드 모듈(11)에 기본 정보(카드ID, 사용자ID, 옵션정보 등)를 제공하여, 교통카드 모듈(11)에 교통카드를 포함시켜 교통카드 발급을 마무리 할 수 있다. 이 때, 잔액은 0원이 된다. 상기 기본 정보에는 고유키는 포함되지 않는다.

즉 이러한 일련의 과정을 통해서, 교통카드는 발급이 되고, 발급된 교통카드는 사용자가 교통카드 앱 또는 교통카드 모듈을 이용해서 확인이 가능하다. 하지만, 교통카드 앱이나 모듈에는 교통카드의 결제 및 충전의 핵심인 고유키 등의 중요한 정보는 포함하지 않고, 중요한 정보는 사용자ID를 기반으로 별도의 보안모듈에 저장되어 있고, 그 외의 정보는 일반 저장장치에 저장되어 있게 된다.

이렇 형태로 구현을 하게 되면, 고유키를 노출할 일도 없고, 스마트폰을 변경을 하더라도, 카드를 잃어버리더라도, 사용자ID에 의해서, 카드ID, 금액 등이 별도의 모듈 및/또는 저장소에 저장되어 있으므로, 신규카드가 아닌 본인의 사용하던 카드를 다시 사용할 수 있게 된다.

도 2 내지 도 7은 교통카드 발급시스템이 교통카드를 발급하는 방법의 흐름도이다.

S100단계를 통해, 사용자는 단말(10)에 설치된 교통카드 앱 또는 교통카드 모듈이 내장되어 있는 은행앱을 통해서 발급서버(발급시스템에서는 발급부(100)에 대응된다) 교통카드 발급을 요청한다. 요청을 할 때, 발급 서버에 전송되는 데이터는 사용자의 정보, 즉 은행앱에서 사용하는 CI 또는 스마트폰에서 사용하는 사용자 이메일 등 사용자를 식별할 수 있는 사용자ID를 포함된다.

S100단계는 교통카드 앱 또는 교통카드모듈을 최초 실행 시키는 단계(S110), 교통카드 발급 여부에 대한 안내문이 도시하는 단계(S120), 사용자는 교통카드 발급을 원하는 경우에는 안내문에 따라 정보를 입력하는 단계(S130), 교통 카드발급을 요청하는 단계(S140)를 포함할 수 있다.

발급서버는 신규 교통카드 발급을 요청이 오면, S200단계에서는 신규 교통카드에 부여할 카드ID를 획득한다. S200단계는 발급서버가 교통카드사 서버에 발급할 카드ID를 요청/수신하는 단계(S210), 수신된 카드ID를 저장부에 저장하는 단계(S220), 저장된 카드ID를 저장부로부터 읽어오는 단계(S230)를 포함할 수 있다.

S300단계를 통해서, 발급서버는 발급SAM에 신규발급할 카드의 고유키를 요청하고, 수신한다. S300단계는 발급서버가 발급SAM에 카드ID에 대응되는 고유키를 요청하는 단계(S310), 발급서버가 발급SAM으로부터 암호화된 고유키와 고유키를 확인하는 서명을 수신하는 단계(S320), 수신된 서명을 이용하여 고유키가 정확한지 확인하는 단계(S330)를 포함할 수 있다. 각각의 단계에는 별도의 서명을 통해서, 발급서버와 발급SAM을 확인 또는 인증할 수 있는 절차를 추가로 포함될 수 있다.

S400단계를 통해서, 발급서버는 상기 발급된 서명, 카드ID, 사용자ID, 옵션정보를 포함하여 보안이 필요한 데이터와 보안이 필요하지 않은 데이터로 분리하여 획득할 수 있다. 각각의 데이터를 한쌍인 것을 식별할 수 있는 인덱싱을 각각의 데이터에 포함시켜서, 보안이 필요하지 않은 데이터 및 인덱싱을 포함하는 제1데이터, 보안이 필요한 데이터 및 인덱싱을 포함하는 제2데이터를 획득할 수 있다.

S400단계는 발급서버가 암호화된 고유키, 카드ID, 사용자ID, 옵션정보, 서명을 포함하는 데이터를 별도로 구성된 제1보안모듈에 전송하는 단계(S410), 제1보안모듈은 암호화된 고유키를 복호화하여 서명과 확인하는 단계(S420), 고유키가 정확하면, 제1보안모듈이 보안이 필요한 데이터 및 보안이 필요하지 않은 데이터를 분리하는 단계(S430), 제1보안모듈이 분리된 데이터 중 보안이 필요한 데이터를 암호화하고, 서명을 생성하는 단계(S440), 보안이 필요한 데이터 및 보안이 필요하지 않은 데이터에 각각 인덱싱하는 단계(S450), 발급서버는 제1보안모듈로부터 서명을 포함한 인덱싱된 보안이 필요한 데이터 및 보안이 필요하지 않은 데이터를 가져오는 단계(S460)를 포함할 수 있다. 각각의 단계에는 별도의 서명을 통해서, 발급서버와 제1보안모듈을 확인 또는 인증할 수 있는 절차를 추가로 포함될 수 있다.

S500단계를 통해서, 발급서버는 상기 인덱싱된 보안이 필요한 데이터 및 보안이 필요하지 않은 데이터를 나누어서 저장한다. S500단계는 인덱싱된 보안이 필요하지 않은 데이터를 제2저장부에 저장하는 단계(S510), 인덱싱된 보안이 필요한 데이터를 제2보안모듈에 저장하는 단계(S520)을 포함할 수 있다. 발급서버와 제2보안모듈 및/또는 제2저장부를 확인 또는 인증할 수 있는 절차를 추가로 포함될 수 있다.

S600단계를 통해서, 발급서버는 교통카드 앱 또는 교통카드 모듈이 저장할 수 있도록 인덱싱 정보를 포함하는 소정의 정보를 교통카드 앱 또는 교통카드 모듈에 제공하여 카드를 발급한다. 발급서버와 단말을 확인 또는 인증할 수 있는 절차를 추가로 포함될 수 있다.

10번대로 나뉘는 각각의 단계는 모두를 포함할 수 있고, 그 일부만을 포함할 수 있다.

상기와 같은 과정을 거치면, 교통카드 앱 또는 교통카드 모듈은 신규 교통카드를 발급하게 되지만, 실제로 중요한 정보 등은 제1보안모듈에 저장을 하게 된다. 이렇게 되면, 후술할 결제 또는 충전 시, 교통카드 앱 또는 교통카드 모듈에 저장되어 있는 인덱싱 정보를 기초로 제1보안모듈에 저장되어 있는 정보를 이용하여, 충전 또는 결제를 할 수 있다.

도 8는 교통카드 오프라인 충전 시스템에 대한 개념도이다.

앞서 설명한 바와 같이, 본 발명의 교통카드 발급시스템은 보안이 필요한 데이터(고유키, 충전금액 등)들은 별도의 제2보안모듈에 저장되어 있다. 따라서, 충전을 하기 위해서는 충전 단말기, 교통카드앱 또는 교통카드 모듈, 충전 인증서버, 제2보안모듈간의 소정의 통신방식에 의해서 연결되어 있고, 소정의 통신방식은 장치 간에 따라 서로 다를 수 있다.

사용자ID, 카드ID를 포함하는 정보가 저장되어 있는 교통 카드(여기서 교통카드는 교통카드 앱이 될 수도 있고, 교통카드 모듈이 될 수도 있다.)를 포함하는 단말과 충전SAM을 포함하는 충전 단말기 간의 소정의 데이터를 이용하여 충전을 시작을 하면, 상기 교통 카드는 충전 라이브러리를 포함하는 운용부와 상기 충전 단말기 간 서명을 교환하는 작업을 한다. 이 과정에서 고유키는 제2보안모듈에 존재하므로 서명의 검증은 제2보안모듈에서 이루어진다. 즉 제2보안모듈에 있는 교통카드의 고유키 및 잔액 등 정보를 충전SAM에 전함으로써, 충전을 할 수 있다.

운용부는 서명을 생성하고 검증할 수 있는 별도의 모듈을 포함할 수 있다.

상기의 과정동안에 충전을 위해 돈을 지불하는 방식은 현금이나 카드로 할 수 있고, 은행앱에 교통카드 모듈로 포함되어 있는 경우에는 은행앱에서 충전을 해주는 곳으로 돈을 송금하는 방식이 될 수 있다.

또한 상기 과정동안에 제2저장부에 저장되어 있는 보안이 필요하지 않은 데이터도 인덱싱을 매칭하여 사용되어 질 수 있다.

도 5는 오프라인 충전을 위한 장치 간 주요 단계를 나타낸 흐름도이다.

오프라인으로 본 발명에서 발급된 교통카드를 충전하는 방법은 충전 단말기는 교통카드에 충전 시작을 알리는 단계, 교통카드는 운용부에 서명1을 요청하는 단계; 운용부는 서명1을 생성을 제2보안모듈에 요청하는 단계, 제2보안모듈은 서명1을 운용부에 제공하는 단계, 운용부는 서명1을 교통카드에 송신하는 단계, 교통카드는 수신된 서명1을 충전 단말기에 송신하는 단계, 충전 단말기는 수신된 서명1을 검증하는 단계, 충전 단말기에서 서명1이 올바른 서명이라고 판단되면, 충전 단말기는 서명2를 생성하여 충전을 교통카드에 요구하는 단계, 교통카드는 운용부에 서명2 검증 및 서명3 생성을 요청하는 단계; 운용부는 제2보안모듈에 서명2 검증 및 서명3 생성을 요청하는 단계; 제2보안모듈이 서명2를 검증하는 단계; 제2보안모듈이 서명2가 올바른 서명인 것으로 판단되면, 서명3을 생성해서 운용부에 전송하는 단계, 운용부는 서명3을 교통카드에 전송하는 단계, 교통카드는 수신된 서명3을 충전 단말기에 송신하는 단계, 충전단말기는 서명3을 검증하는 단계, 서명3이 올바른 서명이라고 판단되는 경우 충전을 완료하는 단계를 포함한다.

도 6는 교통카드 온라인 충전 시스템에 대한 개념도이다.

앞서 설명한 오프라인 충전방식의 경우에는 충전 단말기에 충전SAM을 포함하고 있어서, 충전SAM의 인증을 통해서 충전이 되는 방식이었다. 본 발명의 교통카드의 경우에는 고유키와 같은 보안이 필요한 데이터는 교통카드가 아닌, 제2보안모듈에 저장이 되어 있기 때문에, 충전하는 과정에서 제2보안모듈에 저장되어 있는 고유키를 기초로 한, 서명 인증을 하는 과정을 거쳐야 한다.

온라인으로 충전을 하기 위해서는 충전라이브러리를 포함하는 운용부는 충전SAM을 추가로 더 포함하고, 교통카드앱 또는 교통카드 모듈에서 충전을 요청하면(다만, 먼저 돈이 지불되어야 하고, 은행앱을 사용하는 경우에는 은행앱의 송금과정을 통해서 하는 것이 바람직하다.), 운용부는 제2보안모듈에 저장되어 있는 고유키를 기초로 인증 후 충전을 하는 방식이 적용이 된다.

이 과정에서 충전SAM, 교통카드, 운용부, 제2보안모듈 간의 교환키를 검증하기 위해서 서명의 생성, 교환, 검증 과정을 수행할 수 있다.

도 7은 온라인 충전을 위한 장치 간 주요 단계를 나타낸 흐름도이다.

온라인으로 본 발명에서 발급된 교통카드를 충전하는 방법은 교통카드가 운용부에 충전을 요청하는 단계, 운용부는 서명1을 제2보안모듈에 요청하는 단계, 제2보안모듈은 서명1을 생성해서 운용부에 제공하는 단계, 운용부는 서명1을 검증하는 단계, 운용부는 서명1이 올바른 서명이라고 판단되면, 제2보안모듈에 충전 시작을 알리면서, 서명2를 요청하는 단계, 제2보안모듈은 서명2를 생성하여, 운용부에 전송하는 단계, 운용부는 서명2를 검증하는 단계, 서명2가 올바르면, 서명3을 제2보안모듈에 서명3을 요청하는 단계. 제2보안모듈이 서명3을 생성해서 운용부에 전송하는 단계, 운용부는 서명3을 검증해서, 올바른 서명이라고 판단되면, 제2보안모듈에 충전을 완료를 알리는 단계를 포함한다.

도8은 교통카드를 이용하여 결제시스템의 개념도 및 결제방법에 대한 흐름도이다.

결제 시스템은 충전 시스템과 마찬가지로, 제2보안모듈에 저장되어 있는 고유키를 이용하여 결제를 하는 시스템이다.

교통카드, 결제 단말기, 운용부, 제2보안모듈은 소정의 통신방식에 의해서 서로 연결되어 있고, 제2보안모듈에는 고유키를 포함한 보안이 필요한 데이터가 들어 있고, 교통카드로 결제를 하기 위해서는 교통카드는 제2보안모듈에 저장되어 있는 고유키 정보를 요청하여, 결제를 한다. 이 때, 제2저장장치에 저장된 보안이 필요없는 데이터의 경우에는 그 데이터의 정보가 필요 시, 보안이 필요한 데이터와 매칭을 하여 데이터를 사용한다.

본 발명에서 발급된 교통카드를 결제하는 시스템은 결제 단말기(예를 들어 버스단말기)는 교통카드에 결제(지불거래) 시작을 알리는 단계, 교통카드는 운용부에 서명1을 요청하는 단계; 운용부는 서명1을 생성을 제2보안모듈에 요청하는 단계, 제2보안모듈은 서명1을 운용부에 제공하는 단계, 운용부는 서명1을 교통카드에 송신하는 단계, 교통카드는 수신된 서명1을 결제 단말기에 송신하는 단계, 결제 단말기는 수신된 서명1을 검증하는 단계, 결제 단말기에서 서명1이 올바른 서명이라고 판단되면, 결제 단말기는 서명2를 생성하여 결제를 교통카드에 요구하는 단계, 교통카드는 운용부에 서명2 검증 및 서명3 생성을 요청하는 단계; 운용부는 제2보안모듈에 서명2 검증 및 서명3 생성을 요청하는 단계; 제2보안모듈이 서명2를 검증하는 단계; 제2보안모듈이 서명2가 올바른 서명인 것으로 판단되면, 서명3을 생성해서 운용부에 전송하는 단계, 운용부는 서명3을 교통카드에 전송하는 단계, 교통카드는 수신된 서명3을 결제 단말기에 송신하는 단계, 결제 단말기는 서명3을 검증하는 단계, 서명3이 올바른 서명이라고 판단되는 경우 결제를 완료(지불완료)하는 단계를 포함한다.

이상에서 본 발명이 구체적인 구성요소 등과 같은 특정 사항들과 한정된 실시예 및 도면에 의해 설명되었으나, 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐, 본 발명이 상기 실시예들에 한정되는 것은 아니며, 본 발명이 속하는 기술분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형을 꾀할 수 있다.

따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등하게 또는 등가적으로 변형된 모든 것들은 본 발명의 사상의 범주에 속한다고 할 것이다.

10 단말
20 카드사 서버
100 발급부
200 저장부
210 제1저장부
220 제2저장부
310 발급SAM
320 충전SAM
330 결제SAM
400 제1보안모듈
500 제2보안모듈
600 운용부
610 충전라이브러리
620 결제라이브러리
1000 교통 카드 발급 시스템
2000 충전 시스템
3000 결제 시스템

Claims

별도의 단말에 의해서 사용자ID를 포함하는 데이터를 기초로 교통 카드 발급요청에 의해서 교통카드를 발급하는 시스템.