KR102575471B1

KR102575471B1 - 포털사이트 중계 서비스 제공 시스템 및 그 방법

Info

Publication number: KR102575471B1
Application number: KR1020210099609A
Authority: KR
Inventors: 이현수
Original assignee: 이현수
Priority date: 2021-07-29
Filing date: 2021-07-29
Publication date: 2023-09-07
Also published as: KR20230017998A

Abstract

본 발명은 포털사이트 중계 서비스 제공 시스템 및 그 방법에 관한 것으로서, 더욱 상세하게는 SSO(Single Sign On)와 같이 단일계정으로 편리하고 FIDO와 같이 보안 수준이 높은 방법을 이용하여 포털사이트의 포털서버가 사용자의 등록, 인증,탈퇴의 서비스를 제공할 수 있고, 사용자단말기는 포털사이트마다 별도로 아이디, 패스워드를 기억하고 있을 필요 없이 단일한 사용자 아이디와 비대칭키 한 쌍만을 가지고도 각 포털사이트로 직접 접속하는 것과 같은 편리함을 제공하고, 또한, 고객사 웹 서버 입장에서는 상기 PKI 암호화 인증과 성공신호 및 인증정보를 활용한 보조 인증을 이용해서 FIDO 보다 더 안전한 인증 수단을 누리게 해 주는 포털사이트 중계 서비스를 제공할 수 있으며, FIDO와 달리 중계서버를 사용해서 단일계정이 가능하고 포털서버가 중계서버로 주는 성공신호와 사용자단말기가 중계서버로 주는 인증정보를 사용해서 보조인증, 즉 개인키 유출사고 대응 및 이메일 대응, 중계서버의 우회 등록, 인증, 탈퇴의 해킹 대응 및 이메일 대응, 다른 사용자의 아이디로 다른 공개키를 임의의 포털사이트에 등록, 인증, 탈퇴하려는 해킹 대응 및 이메일 대응을 할 수 있고, 포털서버가 중계서버를 통해 사용자단말기로 사용자 난수를 보내고, 이를 사용자단말기가 비대칭키로 전자서명화한 사용자 난수 암호화를 포털서버로 보내며, 포털서버가 사용자단말기가 보낸 전자서명을 사용자 public key를 활용해서 전자서명을 검증한 후, 이를 자신이 보낸 난수와 비교함으로써, 사용자 입장에서는 자신의 private key가 노출되지 않는다면 포털서버마다 별도의 패스워드 관리가 필요없이 1개의 숫자 6자리 핀넘버 또는 생체인증만으로 해커의 replay attack 이 없는 개인의 인증을 확실히 보장할 수 있고, 포털사이트 입장에서는 최종적으로 사용자가 접속시 보낸 매번 달라지는 사용자 난수암호화와 이를 복호화하는 비대칭키의 보안특성으로 사용자임을 확인할 수 있어 보안성을 향상시킬 수 있으며, 중계서버가 구성 요소에 첨가됨으로써, 사용자단말기는 단일계정으로 모든 포털사이트에 가입할 수 있음은 물론 포털사이트가 중계서버로 보낸 성공신호와 사용자단말기가 중계서버로 보낸 인증정보를 활용해서 보조 인증을 한 번 더 물을 수 있으므로 개인키 유출 시 해당 URL의 해킹 사고 대응이나 이메일 대응, 다른 사용자 아이디로 다른 공개키를 등록하는 해킹사고 대응이나 이메일 대응, 또는 중계서버 우회 등록, 인증, 탈퇴의 해킹 대응 및 이메일 대응을 방지할 수 있는 효과가 있다. 또한, 중계서버마다 사용자 수를 임의 배정할 수 있어, 단일계정을 사용해도 수용할 수 있는 사용자 수에 제한이 하나도 발생하지 않는다. 즉, 70억 전 인류가 이 시스템을 사용해서 단일계정으로 묶여도, SSO 및 FIDO 나 블록체인 DID와는 달리 수용할 수 있는 사용자 수에 제한이 없다. 더군다나, 인증 속도인 throughput 이 SSO 및 FIDO 나 블록체인 DID와는 달리 사용자 수가 아무리 늘어나도 전혀 느려지지 않는다. 마지막으로, 본 기술은 사용자단말기가 등록, 인증, 탈퇴 시 마다 매번 포털서버 쪽으로 해당 사용자의 공개키를 전송하기 때문에, 본 기술은 포털서버에 사용자 용 DB가 필요없게 되고, 또한 해당 공개키의 신뢰성을 개개인이 계속 보장할 수 있게 된다. 따라서, 상기 공개키를 개인의 사용자단말기가 해킹되지 않는다면 그 신뢰성을 보장할 수 있다는 점에서, 사용자의 개인키가 해커에 의해 해킹되면 안된다는 똑같은 취약점을 가진 블록체인 DID 와 보안 수준이 비슷하게 된다. 즉, 해킹의 취약점이 개개인의 사용자단말기 밖에 없다는 점에서 본 기술과 블록체인 DID 의 보안 수준이 비슷하게 된다. 이때, 본 기술의 해킹 취약점은 중계서버에 저장된 등록데이터가 하나 더 존재하게 되지만, 중계서버에서 사용자 최초 등록 시에 미리 저장된 등록데이터의 경우, 등록데이터가 사용자 아이디, 공개키, 이들의 전자서명 값으로 구성되어 있어서 주기적으로 전자서명 검증을 하면 해커의 중계서버 등록데이터 위변조를 탐지할 수 있다는 점에서 보안이 방어가 된다. 또한, 상기 중계서버들과 각각의 고객사 웹 서버가 전용해로 사용하는 각각의 상기 포털서버들을 클라우드에 올려서 해당 인프라를 충분히 갖춰 놓기만 하면, 기존의 facebook login 이나 기존의 Google login 과 같은 social SNS login처럼, 고객사 웹 서버는 사용자 아이디별 성공 토큰과 실패 메시지를 사용해서 고객사 웹 서버 자신과 고객사 웹 서버 자신 전용의 포털서버를 간단히 연동시킬 수 있다. 따라서, 본 기술의 상기 중계서버들과 본 기술의 상기 포털서버들을 클라우드에 충분히 실행시켜 놓으면, 고객사 웹 서버는 기존의 social SNS login처럼, 고객사 웹 서버 자신과 클라우드 상의 해당 고객사 웹 서버 전용 포털서버와 간단하고 빠르게 연동할 수 있게 되어서, 고객사 웹 서버는 간편하고 빠른 시간 내에 상기 클라우드 인프라를 활용해서 고객사 웹 서버 자신의 서비스를 시작할 수 있게 된다.

Description

포털사이트 중계 서비스 제공 시스템 및 그 방법{SYSTEM AND METHOD FOR PROVIDING PORTAL-SITE RELAY SERVICE}

본 발명은 포털사이트 등록시 저장한 1쌍의 비대칭 키와 매번 등록, 인증, 탈퇴시마다 발생하는 사용자 난수를 활용하여 포털서버가 사용자임을 확인하는데, 중계서버(relay server)를 사용해서 단일계정, 개인키의 유출 사고 대응, 다른 사용자 아이디의 다른 공개키 등록, 인증, 탈퇴 및 중계서버 우회해킹 등을 방지할 수도 있다. 사용자가 맨 처음 포털사이트로 중계서버를 통해서 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 보낼 때, 중계서버에서 전자서명 검증 성공 후에 등록데이터를 저장한다. 이때 전자서명 검증이란 등록데이터 내의 사용자 전자서명 값을 같은 등록데이터 내의 공개키로 복호화한 후에 이 복호화한 것을 등록데이터의 나머지 정보들, 즉, 사용자 아이디, 공개키 등의 정보를 해쉬화 한 것과 일치하는지를 검증하는 것을 의미한다. 이후, 중계서버에서 자신이 받은 이 등록데이터를 포털서버로 보낸다. 이후, 이를 받은 포털서버는 사용자가 등록, 인증, 탈퇴할 때마다 매번 달라지는 사용자 난수를 중계서버를 통해 사용자단말기로 전송하고, 사용자단말기가 최종적으로 이 난수를 비대칭 키인 개인키로 암호화해서 바로 포털사이트로 전송한 후, 포털서버가 사용자 공개키로 복호화한 것과 자신이 보낸 난수의 해쉬와 비교해서 서로 같은지 전자서명 검증하면, 비대칭 키의 특성상 전자서명한 사람이 사용자일 수밖에 없음을 확인할 수 있다. 그리고, 프로세스 상 맨 처음, 등록데이터를 사용자 아이디 내에 있는 지역번호와 공개키 안의 중계서버 URL 주소를 사용해서 사용자단말기에서 해당 중계서버로 보내서 사용자의 최초 등록 시에는 해당 등록데이터 내의 사용자 아이디가 중계서버에 이미 있는지 여부를 조사하고 있을 시 프로세스를 중단한다. 이후, 중계서버에서 해당 등록데이터를 전자서명검증하고 성공 시 중계서버에 저장한다. 그리고, 사용자의 최초 등록 시 이후의 등록, 인증, 탈퇴의 경우에는 해당 등록데이터를 사용자 아이디 내에 있는 지역번호와 공개키안의 중계서버 URL 주소를 사용해서 사용자단말기에서 해당 중계서버에 보내고, 이를 해당 중계서버에 이미 저장된 등록데이터와 사용자 아이디를 기준으로 비교해서 일치하는 것이 1개만 있어야 하기 때문에 단일계정을 확인할 수 있음은 물론, 이후, 사용자단말기가 중계서버로 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 인증정보를 shuffle 번호대로 shuffle(데이터를 shuffle 번호에 해당되는 규칙으로 자른 후에 섞는다.) 한 후에 중계서버로 보내고, 중계서버에서 shuffle 번호대로 다시 복원한 후에(shuffle 번호대로 섞여진 데이터를 shuffle 번호대로 원복한다.) 중계서버에 이미 저장된 등록데이터와 비교해서 아이디와 공개키 등이 일치하지 않으면 프로세스를 중단해서 단일계정을 한번 더 확인할 수 있다. 이후, 사용자단말기가 포털서버로 상기 인증정보를 shuffle 번호대로 shuffle해서 보내고, 포털서버에서는 해당 인증정보를 shuffle 번호대로 복원한 후 전자서명 검증한다. 여기서 전자서명 검증이란, 인증정보 내의 사용자 전자서명값을 인증정보 내의 공개키로 복호화한 후에 이 복호화한 것을 shuffle 번호와 shuffle 번호 해쉬를 제외한 나머지 정보들, 즉, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬 등을 해쉬한 것과 비교해서 서로 일치하는지 검증하는 것을 의미한다. 이후, 포털서버가 받은 인증정보 내의 사용자 아이디와 난수값을 포털서버 자신이 보낸 사용자 아이디와 난수값과 비교해서 성공시 사용자임을 확인하고 포털서버 자신이 받고, shuffle 번호대로 복원된 데이터인 인증정보를 shuffle 번호와 shuffle 해쉬만 바꿔서 성공신호를 만들고 해당 shuffle 번호대로 다시 shuffle 된 성공신호를 포털서버에서 중계서버로 다시 보내고 이 shuffle 된 성공신호를 중계서버에서 shuffle 번호대로 복원한 후에, 이 성공신호를 상기 사용자단말기가 중계서버에게 보내고 shuffle 번호대로 복원되어 중계서버에 임시 저장된 인증정보와 중계서버에 임시 저장된 등록데이터를 비교하는 방법으로 한 번 더 사용자임을 확인하는 보조인증을 할 수 있다. 즉, 포털서버가 마지막으로 받은 데이터와 사용자단말기가 중계서버로 보낸 데이터를 중계서버에서 한번 더 서로 비교해서 포털서버가 마지막으로 받은 것이 사용자단말기가 보낸 것과 일치하는지, 한 번 더 중계서버에서 보조인증을 하게 된다. 즉, 포털서버가 등록, 인증, 탈퇴를 위해 받은 인증정보 데이터가 정말로 맞는지 안 맞는지를 사용자단말기가 중계서버로 보낸 등록데이터와 인증정보를 상기 포털서버가 마지막으로 받은 인증정보 데이터와 중계서버에서 한번 더 비교해서 맞는지 틀린지를 한 번 더 중계서버에서 확인하게 된다. 이를 통해 개인키 유출 사고 대응 및 중계서버 우회 등록, 우회 인증, 우회 탈퇴 및 다른 사용자의 아이디로 다른 공개키를 등록, 인증, 탈퇴 하려는 해킹을 탐지하고 이메일로 사고 내용들을 각각 대응하고 각각의 해킹에 대해서 대응할 수 있다. 다시 말해서, 상기에서 중간자 공격을 방어하기 위해 사용자단말기가 중계서버에 shuffle 된 인증정보를 보내고 포털서버가 중계서버로 shuffle 된 성공신호를 보낼 때, 중계서버에서 상기 인증정보와 성공신호를 각각 shuffle 번호대로 원복한 후에, 이 성공신호와 인증정보 그리고 사용자단말기가 상기 인증정보 전에 미리 중계서버에 보내고 중계서버에 미리 임시 저장되어 있는 등록데이터를 서로를 비교해서 보조 인증하는 방법, 즉 이 보조인증을 통해서 개인키 유출 사고 대응 및 이메일 대응, 중계서버 우회 등록, 우회 인증, 우회 탈퇴 대응 및 이메일 대응, 다른 사용자의 아이디로 다른 공개키를 등록, 인증, 탈퇴 하려는 해킹 대응 및 이메일 대응을 하는 기존 기술엔 없고 효과적이고 보안성이 높은 방법을 사용하는 포털사이트 중계 서비스 제공 시스템 및 그 방법에 관한 기술이다.

인터넷 상에서 사용자는 각 포털사이트마다 별도로 로그인 정보를 기억하고 있어야 한다. 물론 아이디 패스워드를 모두 동일하게 하여 관리하는 방법도 있으나, 요즘에는 각 포털사이트마다 보안상 문제로 패스워드 구성 요건이 서로 다르기도 하여 일일이 통일시키는 것도 매우 번거로운 일이다. 더구나, 사이트마다 암호를 일치시키면 텍스트 암호의 취약점인 credential stuffing 취약점이 생겨 해커가 해킹을 하기가 아주 쉬워진다. 또한, 텍스트 암호화는 오래된 기술이기 때문에 피슁과 같은 해킹 공격에 매우 취약하다.

그리고, 각 포털사이트는 가입하는 각 사용자의 로그인 정보를 관리해야 하는 부담을 갖고 있다. 단순히 아이디 패스워드만 관리하면 되는 것이 아니다. 즉, 사용자가 아이디나 패스워드를 잊어버렸을 때는 그 외의 기억할 정보를 제공해야 하거나, 또는 여러 가지 개인 인증방법을 거치도록 하여 아이디 패스워드를 새로 부여하는 등, 시스템 수행상의 여러 가지 적지 않은 비용이 발생하는 문제가 있어 왔다.

또한, 기존의 FIDO(Fast Identity Online)는 서버에서 임의의 난수(server challenge)를 발생하여 클라이언트에게 주고 이를 클라이언트가 해쉬화한 후 비대칭키로 signature화를 해서 서버로 다시 돌려주는 방식이므로 해커가 다른 사용자 아이디로 다른 공개키를 등록하는 것이 이론적으론 가능하다.

또한, SSO(Single Sign On)의 경우, 해커의 스니핑 공격에 취약한 텍스트 암호화의 한계도 가지고 있지만, 사용자 수가 늘어나게 되면, 토큰을 발행하고 사용자 등록, 인증, 탈퇴를 실행하는 중앙서버의 DB 한계에 부딪치게 된다. 하지만, 본 기술은 사용자 아이디 내의 지역번호를 사용해서 사용자들을 여러 중계서버들에게 임의로 지정해서 분산시킬 수 있기 때문에, 사용자 수가 아무리 늘어나게 되어도 중계서버의 DB 한계가 발생하지 않는다.

또한, 본인이 출원 등록한 기존 포털사이트 중계 서비스 특허는 난수를 단방향으로 사용자단말기에서 중계서버를 통해 포털서버로 보내고 난수의 비대칭키 암호화는 사용자단말기가 바로 포털서버 쪽으로 단방향으로 보내서 포털서버에서 사용자를 인증하는 것이 핵심인데, 이 경우에 해당 2개의 패킷, 즉, 해당 난수와 해당 난수 암호화를 해커가 스니핑해서 해커가 계속 사용하게 되면 해당 사용자인척하는 해커의 등록, 인증, 탈퇴가 항상 가능하게 되는 치명적인 취약점이 발생하게 된다. 따라서, 상기 본인이 이전에 출원등록이 성공한 포털사이트 중계 서비스 특허는 해커의 스니핑 공격이 성공하면 해커가 해당 사용자인척 하면서 얼마든지 등록, 인증, 탈퇴가 가능한 아주 치명적인 보안 취약점이 생기게 된다. 하지만, 본 발명은 이 치명적인 단점을 FIDO와 같은 원리로 난수를 포털서버에서 중계서버를 통해 사용자로 보내고 사용자가 이를 다시 비대칭키로 암호화해서 포털서버로 바로 보내는 것으로 수정하였다. 하지만, FIDO와는 달리 중계서버를 사용해서 단일계정, 사용자 개인키 유출 시 사고대응 및 이메일 대응, 중계서버 우회 등록, 우회 인증, 우회 탈퇴 시 사고대응 및 이메일 대응, 그리고 해커가 다른 사용자의 아이디로 다른 공개키를 임의의 포털사이트에 등록, 인증, 탈퇴 할 시의 사고대응 및 이메일 대응을 추가로 할 수 있다. 또한, 본 기술은 여러 회사들의 서비스들에 해당되는 여러 고객사 웹 서버들과 포털서버들을 쓰는 사용자 수가 아무리 많아져도 중계서버만 늘리면 단일계정이 계속 유지되면서도 인증 속도인 throughput 속도나 중계서버의 부하가 전혀 늘어나지 않아서, 단일계정을 가정 시, 중앙서버의 DB의 한계나 인증 속도인 throughput 속도의 지연, 또는 서버 부하의 한계 때문에 사용자 수에 제한을 받을 수밖에 없는 FIDO, SSO, 및 blockchain DID 에 비해 본 기술은 사용자 수에 제한을 전혀 받지 않는다. 그리고, 상기에서 중간자 공격을 방어하기 위해 사용자단말기가 중계서버에 shuffle 된 인증정보를 보내고 포털서버가 중계서버로 shuffle 된 성공신호를 보낼 때, 중계서버에서 각각의 shuffle 번호대로 복원한 인증정보와 성공신호를 사용자단말기가 중계서버로 상기 인증정보 전에 미리 보내고 중계서버에 미리 임시 저장된 등록데이터와 비교하는 보조인증 방법, 즉, 포털서버가 마지막으로 받은 것이 사용자단말기가 보낸 것이 맞는지를 한 번 더 검증한다. 이때, 이 shuffle 방법은 shuffle 번호대로 해당 인증정보나 성공신호, 즉 원본들과 원본을 해쉬한 것들을 shuffle, 즉 원본들과 원본 해쉬들의 패킷을 shuffle 번호대로 잘라서 서로 섞는 방법으로, 해커는 shuffle 규칙을 모르기 때문에 의도대로 데이터를 변조할 수 없고, 임의로 데이터를 변경할 수밖에 없어, 받는 쪽에서 shuffle 번호대로 원복하면 원본들과 원본 해쉬들의 비교가 다르게 되어 해커의 임의의 데이터 변경, 즉 중간자 공격을 탐지할 수 있다. 이 방법은 기존 기술에 비해 코딩 상에서 구현할 수 있고 연산이 비교적 덜해서 보다 효과적이고, 해커의 중간자 공격을 막을 수 있고, 해커가 데이터를 임의로 변경 시 거의 다 탐지할 수 있어 보안성이 매우 높은 방법이다. 하지만, https 와 같은 TLS 암호화 통신을 사용하는 경우엔, 암호화 때문에 해커가 임의로 패킷을 변경할 수 밖에 없는데, 이러면 패킷을 받는 쪽에서 복호화하면, 상기 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들이 서로 완벽하게 일치하지 않게 되어 중간자 공격이 탐지가 가능하다. 따라서, https 와 같은 TLS 통신에선 상기 shuffle 번호에 따라 shuffle을 하지 않고 원본과 원본의 해쉬값들만 보내고 받게 되어도 중간자 공격을 탐지할 수 있다.

그러므로 SSO(Single Sign On)와 같이 단일계정으로 편리하고 FIDO와 같이 보안 수준이 높은 방법을 이용하여 포털사이트 중계 서비스가 사용자의 등록, 인증, 탈퇴의 서비스를 제공할 수 있다. 여기서, 본 기술은 고객사 웹 서버 URL 마다 별도로 아이디, 패스워드를 기억하고 있을 필요 없이 단일한 사용자 아이디와 비대칭키 한 쌍만을 가지고도 모든 각각의 고객사 웹 서버로 직접 접속할 수 있는 단일계정의 편리함과, 포털사이트 입장에서는 사용자의 등록, 인증, 탈퇴 시마다 매번 달라지는 난수와 해당 난수의 비대칭키 암호화를 통해 replay 공격이 불가한 안전한 인증 수단을 누리게 해 주는 포털사이트 중계 서비스를 제공하며, 중계서버를 활용해서 사용자에게 개인키 유출 사고 대응 및 이메일 대응, 중계서버 우회 등록, 우회 인증, 우회 탈퇴 시 사고 대응 및 이메일 대응, 다른 사용자 아이디로 다른 공개키의 등록, 인증, 탈퇴 시도 시 사고 대응 및 이메일 대응하는 등의 높은 보안수준을 제공해 주는 포털사이트 중계 서비스 제공 시스템 및 그 방법의 개발이 절실히 요구되고 있는 실정이다.

KR 10-2015-0137518(2015.06.28)

따라서 본 발명은 상기와 같은 문제점을 해결하기 위하여 착상된 것으로서, SSO(Single Sign On)와 같이 단일계정으로 편리하고 FIDO와 같이 보안 수준이 높은 방법을 이용하여 고객사의 웹 서버가 사용자의 등록, 인증, 탈퇴의 서비스를 제공할 수 있는 포털사이트 중계 서비스 제공 시스템 및 그 방법을 제공하는데 그 목적이 있다.

본 발명의 다른 목적은 사용자단말기는 고객사 웹 서버 마다 별도로 아이디, 패스워드를 기억하고 있을 필요 없이 단일한 사용자 아이디와 비대칭키 한 쌍만을 가지고도 각 고객사 웹 서버로 직접 접속하는 것과 같은 편리함과 고객사 웹 서버 입장에서는 난수와 난수의 비대칭키 암호화를 사용해서 해커의 replay 공격이 없는 안전한 인증 수단을 누리게 해 주는 포털사이트 중계 서비스를 제공할 수 있는 포털사이트 중계 서비스 제공 시스템 및 그 방법을 제공하는데 있다.

본 발명의 다른 목적은 FIDO와 달리 중계서버를 사용해서 단일계정이 가능하고 사용자가 등록, 인증, 탈퇴 시 사용자단말기가 포털서버에게 shuffle 번호대로 shuffle 해서(즉, 데이터를 shuffle 번호의 규칙대로 자르고 섞어서) 주고 포털서버에서 shuffle 번호대로 원복에 성공한 인증정보의 전자서명이 검증되어 등록, 인증, 탈퇴를 확인하게 한 후에, 상기 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호로 만든 후에 이를 다시 포털서버에서 중계서버로 해당 shuffle 번호대로 shuffle 해서 주고, 중계서버에서 이 성공신호를 shuffle 번호대로 복원 성공한 후, 이 성공신호와 사용자단말기가 미리 중계서버로 shuffle 번호대로 shuffle해서 미리 보내고 중계서버에 shuffle 번호대로 원복에 성공하고 중계서버에 미리 임지 저장된 인증정보 및 상기 인증정보전에 사용자단말기가 중계서버로 보내고 중계서버에 임시 저장된 등록데이터를 서로 비교해서 성공 시, 즉, 사용자단말기가 중계서버로 보낸 인증정보와 등록데이터들이, 포털서버가 사용자단말기로부터 사용자의 등록, 인증, 탈퇴를하기 위해서 마지막으로 받은 인증정보를 shuffle 번호와 shuffle 번호 해쉬만 바꿔서 해당 포털서버에서 중계서버로 보낸 성공신호와 일치하는 지 중계서버에서 한 번 더 검토해서 사용자임을 한 번 더 보조적으로 확인한다. 즉, 사용자 인증을 수행하는 포털서버에서 인증을 수행하기 위해 마지막으로 받은 데이터가 사용자가 보낸 데이터와 같은지를 중계서버에서 한번 더 검증, 즉, 보조인증을 한번 더 한다. 이런 보조인증을 활용해서 사용해서 개인키 유출사고 대응 및 이메일 대응, 중계서버의 우회 등록, 우회 인증, 우회 탈퇴의 해킹 대응 및 이메일 대응, 그리고 다른 사용자의 아이디로 다른 공개키를 임의의 포털사이트에 등록, 인증, 탈퇴하려는 해킹 대응 및 이메일 대응하는 포털사이트 중계 서비스 제공 시스템 및 그 방법을 제공하는데 있다.

본 발명의 다른 목적은 각 사용자단말기는 별도의 패스워드를 관리하지 않고도, 포털서버가 중계서버를 통해 사용자단말기로 사용자 난수를 보내고, 이를 사용자단말기가 비대칭키로 전자서명한 사용자 난수 암호화를 사용자 난수 원본 데이터와 함께 바로 포털서버로 보내며, 포털서버가 이 전자서명값을 사용자 public key를 활용해서 전자서명을 검증하고 이 검증된 난수 정보를 자신이 사용자에게 보낸 난수정보와 비교함으로써, 사용자 입장에서는 자신의 private key가 노출되지 않는다면 개인의 인증이 확실히 보장되고, 포털사이트 입장에서는 사용자가 접속시마다 포털서버가 중계서버를 통해 사용자단말기로 매번 보낸 달라지는 사용자 난수와, 이때마다 사용자단말기가 포털서버로 바로 보낸 난수의 비대칭키 암호화를 복호화한 것을 서로 비교하는 비대칭키의 보안특성으로 사용자임을 확인할 수 있어 해커의 replay 공격을 방지하게 되어 보안성이 향상될 수 있는 포털사이트 중계 서비스 제공 시스템 및 그 방법을 제공하는데 있다.

본 발명의 다른 목적은 중계서버가 구성 요소에 첨가됨으로써, 사용자단말기는 단일계정으로 모든 포털서버에 최종적으로 등록, 인증, 탈퇴할 수 있음은 물론, 포털서버에서 상기 인증정보를 전자서명검증해서 등록, 인증, 탈퇴 성공 후에 포털서버가 사용자단말기로부터 받은 인증정보를 shuffle 번호와 shuffle 번호 해쉬만 바꿔서 성공신호를 만든 후에, 이를 포털서버에서 중계서버로 shuffle 번호대로 shuffle 된 성공신호를 보내고 중계서버에서 상기 성공신호를 다시 shuffle 번호대로 원복한다. 이때, 중계서버에서 상기 포털서버가 받은 인증정보가 사용자단말기가 중계서버로 보낸 인증정보 및 등록데이터와 진짜 맞는지 틀리는지를 상기 성공신호와 상기 인증정보 및 상기 등록데이터를 중계서버에서 비교해서 한 번 더 확인한다. 즉, 포털서버가 받은 내용이 사용자단말기가 보낸 내용과 맡는지 중계서버에서 한 번 더 확인하는 보조 인증을 한 번 더 실행한다. 이 보조 인증 때문에, 개인키 유출 시 해당 URL의 사고 대응 및 이메일 대응이나, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하는 해킹 대응 및 이메일 대응 또는 중계서버 우회 등록, 우회 인증, 우회 탈퇴의 해킹 대응이나 이메일 대응을 할 수 있다. 그리고, 상기에서 사용자단말기가 중계서버에 인증정보를 보내고, 또는 사용자단말기가 포털서버로 상기 똑같은 인증정보를 보내고, 또는 포털서버가 중계서버로 성공신호를 보낼 때, 중간자 공격을 방어하기 위해 상기 인증정보와 성공신호를 shuffle 번호대로 shuffle 해서(즉, 데이터를 shuffle 번호의 규칙대로 자르고 섞어서) 보내고 받는 쪽에서 shuffle 번호대로 원복한 후에, 인증정보와 성공신호내의 원본들과 원본의 해쉬들에서 원본들을 해쉬한 것들과 원본의 해쉬들을 서로 비교해서 하나라도 불일치하는 경우가 없는 것을 검증한다. 이러면, 해커는 상기 인증정보 및 성공신호의 데이터들이 shuffle 번호에 따라서 어떻게 shuffle 되어 있는지를 몰라, 상기 네트워크 구간에서 인증정보나 성공신호를 의도대로 변조를 못하게 된다. 따라서, 해커가 shuffle 된 인증정보 및 성공신호를 의도대로 변경 못하고, shuffle 된 인증정보 및 성공신호를 의도대로가 아닌 임의로 변경할 수밖에 없는데, 이럴 경우에도 shuffle 번호대로 원복한 인증정보 및 성공신호 내의 원본과 원본의 해쉬들에서 원본들을 해쉬한 것들과 원본의 해쉬들을 서로 비교해서 하나라도 불일치하는 경우가 있다면, 이런 임의 변경까지 탐지가 가능하다. 왜냐면, 해커가 원본을 임의로 바꾸면, 이를 해쉬한 것과 원본의 해쉬가 틀려지고, 원본의 해쉬를 바꾸면 이것과 원본을 해쉬한 것이 틀려지고, 원본과 원본의 해쉬를 동시에 바꾸면, 원본을 해쉬한 것과 원본의 해쉬가 해쉬 알고리즘의 특성 상 서로 틀려지게 될 확률이 아주 높아진다. 즉, 이 shuffle 기술은 기존 암호화 기술에 비해 연산이 적으면서도 shuffle 번호에 따른 규칙을 알려면 해당 소스코드가 담긴 서버를 해킹해서 해당 소스코드를 decompile 하고 또 해석해야 되기 때문에 효율적인 암호화 기술이 될 수 있다. 하지만, https 와 같은 TLS 암호화 통신을 사용하는 경우엔, 암호화 때문에 해커가 임의로 패킷을 변경할 수밖에 없는데, 이러면 패킷을 받는 쪽에서 복호화하면, 상기 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들이 상기 설명처럼 서로 완벽하게 일치하지 않게 되어 중간자 공격이 탐지가 가능하다. 따라서, https 와 같은 TLS 통신에선 상기 shuffle 번호에 따라 shuffle을 하지 않고 원본과 원본의 해쉬값들만 보내게 되어도 중간자 공격을 탐지할 수 있다. 따라서, 본 특허에선 shuffle 번호대로 데이터를 짤라서 서로 섞는 기능인 이 shuffle 기능을 필요시에 따라 사용해도 되고 사용안해도 되는 옵션기능으로 정의하고자 한다. 즉, shuffle 기능이 없을 때에는 shuffle 번호나 shuffle 번호 해쉬가 없이, 원본과 원본의 해쉬들의 데이터를 그대로 보내고 그대로 받게 하는 보안성이 높은 방법을 사용하는 포털사이트 중계 서비스 제공 시스템 및 그 방법을 제공하는데 있다.

본 발명의 다른 목적은 SSO(Single Sign On) 의 경우, 중앙서버에서 모든 사용자들의 토큰관리를 해야 하는데, 이때 사용자 수가 대한민국의 사람 수인 5000만명만 되어도 토큰관리를 하는 중앙서버의 DB 의 한계가 존재한다. FIDO 와 SSO를 같이 쓰는 경우에도 똑같은 FIDO 중앙서버의 DB 한계, 즉, FIDO 서버의 DB가 모든 사용자를 처리해야 하는 DB의 한계가 존재하게 된다. 또한 blockchain DID 기술에 있어서도 한 노드에 모든 사용자 공개키 정보가 저장되어 있어야 해서, 상기와 같은 DB 의 한계가 역시 존재하게 된다. 반면에 본 기술은 중계서버에 사용자 수를 의도대로 임의로 지정할 수 있어서, 즉, 중계서버들에서 사용자 수를 얼마든지 분산관리 할 수 있기 때문에, 중계서버만 늘리면 70억 지구의 모든 인류를 단일계정으로 묶어도 DB의 아무런 제약이 없고 시간당 인증 건수인 throughput 또한 절대로 느려지지 않는다. 또한, 본 기술은 FIDO처럼 사용자가 각자 개인키를 관리하기 때문에 텍스트 암호화를 사용하는 기존 SSO를 비롯해서 기존 일반 텍스트 암호화 시스템보다 보안성이 높다. 또한, 상기 보조인증을 사용하면, 개인키 유출 사고, 해커의 다른 사용자 아이디를 활용한 다른 공개키 등록, 인증, 탈퇴 및 해커의 중계서버 우회 등록, 우회 인증, 우회 탈퇴를 막을 수 있어 FIDO 보다 높은 수준의 보안을 제공할 수 있다. 또한, 포털서버에 사용자의 공개키를 저장하는 DB 가 없이, 사용자단말기가 등록, 인증, 탈퇴하는 매번 사용자단말기가 포털서버에 공개키를 데이터에 포함시켜 주고, 등록, 인증, 탈퇴하는 매번 포털서버에서 상기 데이터의 전자서명 검증을 하기 때문에, 공개키를 중앙서버에 저장해서 해당 공개키의 위변조에 취약한 기존 중앙서버의 한계를 극복하고, 공개키의 신뢰성을 보장하는 블록체인 DID 에 비해서도 비슷한 보안레벨을 제공할 수 있다. 즉, 본 기술은 사용자가 각각 자신의 개인키와 공개키를 방어하면 되고, 블록체인 DID 또한 사용자의 개인키가 해킹당하면 보안이 뚫리게 되므로, 본 기술과 블록체인 DID 는 같은 수준의 보안을 제공할 수 있다. 또한, 사용자단말기 안에 사용자 아이디, 사용자의 공개키, 및 상기 사용자 아이디와 사용자 공개키를 전자서명한 값에 해당되는 등록데이터를 사용자의 최초 등록 이후에 항상 저장해 놓는다. 이때, 사용자 아이디 내의 지역번호와 공개키 안의 중계서버 URL 주소 때문에 해당 사용자는 항상 같은 중계서버를 쓰게 된다. 즉, 사용자는 자신의 전용 중계서버를 사용해서 고객사의 포털서버 및 고객사 웹 서버로 연결되기 때문에, 단일계정을 보장하면서도 사용자 수에 제한이 없게 된다. 다시 말해, 사용자 아이디 내의 지역번호 및 공개키 안의 중계서버 URL이 사용자 전용 중계서버를 가리키고, 해당 중계서버 내에서 지역번호를 제외한 나머지 사용자 아이디가 중복되지 않으면, 전체 중계서버에서 사용자 아이디의 유일성이 검증된다. 따라서, 사용자 아이디 내에 있는 지역번호를 사용해서 중계서버 1개에 사용자 수를 의도대로 지정할 수 있고 해당 사용자는 자신의 지역번호 때문에 자신 전용의 중계서버만을 사용하면서 포털서버 및 고객사 웹 서버로 접속되기 때문에, 사용자 수가 아무리 늘어나도 중계서버만 늘려서 사용자 수를 분산시키면 되기 때문에 중계서버 DB의 한계가 발생하지 않게 되는 포털사이트 중계 서비스 제공 시스템 및 그 방법을 제공하는데 있다.

본 발명의 다른 목적은 고객사 웹 서버 마다 고객사 웹 서버 전용의 포털서버가 배정 되어 있지만, 이 포털서버가 고객사 웹 서버와 같은 위치에 있지 않고, 중계서버와 함께 클라우드에 있어도 상관 없다는 것이다. 이때, 고객사 웹 서버는 사용자 아이디를 기반으로 포털서버에게 등록, 인증, 탈퇴의 최종 성공 유무를 물어보고, 성공 시 성공 토큰을, 실패 시 실패 메시지를 포털서버로부터 가져오고 이를 사용자단말기가 포털서버로부터 받아와 고객사 웹 서버에게 주는 사용자 별 성공 토큰 내지 실패 메시지와 비교해서 고객사 웹 서버가 최종 성공 여부를 결정하게 할 수 있다. 따라서, 상기 포털서버들과 중계서버들을 클라우드에 올리고 이를 인프라처럼 사용하게 되면, 고객사 입장에선 자신의 고객사 웹 서버를 기존 페이스북 로그인이나 구글 로그인 같은 social SNS login처럼 간단히 본 기술의 인프라와 연동할 수 있게 되는 포털사이트 중계 서비스 제공 시스템 및 그 방법을 제공하는데 있다.

상기　목적을 달성하기 위한 본 발명의 바람직한 일실시예에 따른 포털사이트 중계 서비스 제공 시스템은 고객사 웹 서버에서 사용자단말기로 고객사의 로그인 화면이 디스플레이 되게 하는 기능과, 해당 화면이 디스플레이 되면서 해당 고객사 웹 서버에서 해당 사용자단말기로 고객사 웹 서버 URL 정보와 고객사 웹 서버가 전용으로 사용하는 포털서버의 포털서버 URL 정보들을 같이 전송하는 기능과, 상기 고객사 웹 서버가 사용자단말기로부터 성공 또는 실패 문의를 받을 시, 즉 고객사 웹 서버가 성공 문의를 받을 시에는 고객사 웹 서버가 사용자단말기로부터 사용자 아이디, 웹 쿠키 또는 웹 세션아이디 및 time limit 이 있는 성공 토큰을 https로 받는다. 이후에, 고객사 웹 서버가 포털서버에게 해당 사용자의 등록, 인증, 탈퇴의 성공유무를 사용자 아이디를 사용해서 https로 물어보고 상기 포털서버에서 사용자 아이디 및 time limit 이 있는 성공토큰을 https로 받아온다. 이후, 포털서버에서 포털서버에 임시 저장된 상기 time limit 이 있는 성공 토큰 및 사용자 아이디를 삭제한다. 이후에, 고객사 웹 서버에서 자신이 사용자단말기로부터 https로 미리 받았던 상기 성공토큰과 상기 포털서버에서 받아온 성공토큰을 아이디를 기준으로 비교한 후 일치 시, 고객사 웹 서버에서 사용자단말기에게 성공 화면을 https로 전송하게 하고, 사용자단말기로부터 고객사 웹 서버가 실패 문의를 받을 시에는 사용자단말기로부터 고객사 웹 서버가 사용자 아이디, 웹 쿠키 또는 웹 세션아이디 및 실패 메시지를 https로 받고, 이후, 고객사 웹 서버가 포털서버에게 사용자 아이디를 기준으로 실패여부를 https로 물어보고 해당 사용자 아이디에 해당되는 사용자 아이디와 실패메시지를 포털서버로부터 https로 가져온다. 이때, 실패 메시지는 성공 유무 정보, 사용자 아이디, 인증정보 또는 성공신호 내의 난수정보, 인증정보 또는 성공신호 내의 프로세스 정보, 및 기타 정보를 포함한다. 여기서, 기타 정보에는 해당 사고가 개인키 유출 사고의 등록, 인증, 탈퇴 시도인지, 해커의 다른 사용자의 다른 공개키 등록, 인증, 탈퇴 시도인지, 해커의 중계서버 우회 등록, 우회 인증, 우회 탈퇴 시도인지, 아니면 기타 성공인지를 설명한다. 이하, 실패 메시지는 상기와 같다. 이후, 포털서버에서 포털서버에 임시 저장된 상기 실패 메시지 및 사용자 아이디를 삭제한다. 이후, 고객사 웹 서버에서 사용자단말기로부터 https로 가져온 실패 메시지와 포털서버에서 https로 가져온 실패 메시지를 사용자 아이디를 기준으로 비교해서 일치 시 실패 화면을 고객사 웹 서버에서 사용자단말기로 전송하게 하는 기능과, 고객사 웹 서버에서 등록 성공 시, 고객사 웹 서버에서 고객사 웹 서버 전용 아이디와 본 기술의 사용자 아이디를 매칭시켜 고객사 웹 서버 DB에 이 매칭된 정보들을 저장하는 기능을 갖는 고객사 웹 서버와; 사용자단말기가 상기 고객사 웹 서버로부터 고객사의 로그인 화면을 디스플레이 받고, 이 고객사 로그인 화면을 디스플레이 받을 때 사용자단말기가 상기 고객사 웹 서버로부터 고객사 웹 서버 URL 정보와 고객사 웹 서버가 전용으로 사용하는 포털서버의 포털서버 URL 정보도 같이 받는 기능과, 사용자단말기기에서 중계서버(relay server) 로 상기 포털서버 URL 정보와 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 https 로 전송하고, 이를 받은 중계서버에선 자신이 받은 상기 포털서버 URL 정보를 사용해서 자신이 받은　해당 등록데이터를 해당 포털서버로 전송하고, 이후, 사용자의 최초 등록 시에는, 상기 등록데이터의 아이디(즉, 사용자 이메일주소+지역번호) 내의 지역번호가 해당 중계서버(400)와 맞지 않으면 프로세스를 중단하고, 이후, 해당 중계서버에서 등록데이터 내의 사용자 아이디의 유일성을 검증 후, 실패 시 프로세스를 중단하고, 이후, 중계서버에서 등록데이터의 전자서명을 검증한 후 저장하며, 실패 시 해당 등록데이터를 저장하지 않고 프로세스를 중단하는 기능과, 사용자의 최초 등록 이후의 등록 및 인증, 탈퇴 시에는 중계서버에 이미 저장된 등록데이터와 사용자단말기가 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭이 되더라도 서로를 해쉬값으로 비교한 후 불일치 시 프로세스를 중단하고, 마지막으로 사용자의 최초 등록이나 사용자의 최초 등록 이후의 등록, 인증, 탈퇴 시, 해당 등록데이터를 중계서버에 임시 저장하는 기능과, 상기 중계서버로부터 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송받는 기능과, 사용자단말기에서 중계서버로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬를 shuffle 번호대로 shuffle(인증정보의 데이터를 서로 섞는다) 해서 https로 전송한 후, 중계서버에서 shuffle 번호에 따라서 원본을 복원하는 기능과, 상기 복원 시, 인증정보 내의 원본과 원본의 해쉬값들에서 원본을 해쉬한 것들과 원본의 해쉬값들이 서로 일치하는 지 검증하고 하나라도 불일치 시 프로세스를 중단하는 기능과, 상기 shuffle의 효과는 해커의 중간자 공격을 막아줄 수 있다. 소스코드 상에 있는대로 shuffle 번호에 따라 인증정보(또는 성공신호)를 shuffle 하면(즉, shuffle 번호대로 인증정보 또는 성공신호 등의 데이터를 자르고 섞으면) 해커는 소스코드 상에 있는 shuffle의 규칙을 모르기 때문에 shuffle된 인증정보(또는 성공신호)을 원래대로 복원할 수 없어 의도적으로 원본과 원본의 해쉬값들에서 원본들을 해쉬한 것들과 원본의 해쉬값들이 동시에 서로 일치하도록 바꾸지 못한다. 따라서, shuffle 된 인증정보(또는 성공신호)의 아무 데이터나 바꿀 수밖에 없는데, 이때, 원본이 바뀌면 원본을 해쉬한 것이 원본의 해쉬와 불일치되고, 원본의 해쉬가 바뀌면 원본을 해쉬한 것이 원본의 해쉬와 불일치되고, 원본과 원본의 해쉬가 동시에 바뀌게 되면 데이터의 일부가 바뀌면 해당 데이터의 해쉬값의 전체가 바뀌는 해쉬알고리즘의 특성상 원본을 해쉬한 것과 원본의 해쉬가 또 불일치될 확률이 아주 높다. 따라서, 해커의 의도대로 패킷 데이터를 의도적으로 바꾸는 중간자 공격을 방어할 수 있고, 임의의 패킷 데이터를 바꾸는 중간자 공격의 경우, 원본들과 원본의 해쉬들의 비교에서 원본을 해쉬한 것들과 원본의 해쉬들을 서로 비교함으로서 하나라도 서로 불일치 시에 임의의 패킷 데이터를 바꾸는 중간자 공격을 탐지할 수도 있다. 이 방법을 기존 암호화와 비교하면 기존 암호화는 암호키의 유출여부가 가장 중요한데, DB 나 DB 파일에 있는 암호키를 탈취하기 위해선 해커가 해당 서버 및 DB의 루트 암호들을 알아야 한다. 반면에 이 중간자 공격 대응방법은 shuffle 번호에 따른 shuffle 방법의 유출여부가 중요한데, 해커가 서버의 계정, 즉 아이디와 암호를 해킹하고 해당 서버에서 실행파일을 가져가서 가져간 실행파일을 decompile 한 후에 소스코드를 해독해야 한다. 즉, 실행파일도 해킹해서 가져가야 하고, decompile 후에 소스코드도 한번 더 해석해야 해서, 암호화보다 조금 약하지만 해킹하기가 shuffle을 사용하지 않을 때 보다 좀더 어렵게 된다. 또한, 본 shuffle 기술은 소스코드 상의 shuffle 규칙을 업데이트하기 위해 실행파일을 계속 업데이트할 수도 있다. 하지만, https 와 같은 TLS 암호화 통신을 사용하는 경우엔, 암호화 때문에 해커가 임의로 패킷을 변경할 수 밖에 없는데, 이러면 패킷을 받는 쪽에서 복호화하면, 상기 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들이 상기 설명처럼 서로 완벽하게 일치하지 않게 되어 중간자 공격이 탐지가 가능하다. 따라서, https 와 같은 TLS 통신에선 상기 shuffle 번호에 따라 shuffle을 하지 않고 원본과 원본의 해쉬값들만 보내게 되어도 중간자 공격을 탐지할 수 있다. 따라서, 본 특허에선 shuffle 번호대로 데이터를 짤라서 서로 섞는 기능인 이 shuffle 기능을 필요시에 따라 사용해도 되고 사용안해도 되는 옵션기능으로 정의하고자 한다. 즉 shuffle 기능이 없을 때에는 shuffle 번호나 shuffle 번호 해쉬가 없이, 원본과 원본의 해쉬들의 데이터를 그대로 보내고 그대로 받게한다. 이후, 필요하다면 중계서버에서 해당 인증정보의 전자서명을 검증받고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 않아도 된다. 이후, 인증정보의 사용자 아이디와 공개키가 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디 및 공개키와 불일치 시에도 프로세스를 중단한다. 이후, 해당 인증정보를 중계서버에 임시 저장하는 기능과, 사용자단말기가 고객사 웹 서버로부터 최초 로그인 화면을 받을 시 사용자단말기가 고객사 웹 서버로부터 함께 받은 포털서버 URL 정보를 사용해서, 사용자단말기가 shuffle 번호대로 shuffle 된 상기 인증정보를 상기 포털서버 URL 정보에 해당되는 포털서버(SIDSL 서비스 서버)로 https를 사용해서 전송하는 기능과, 상기 포털서버에서 shuffle 번호대로 복원한 인증정보를 전자서명검증한다. 이때, 전자서명 검증이란, 상기 인증정보에서 shuffle 번호, shuffle 번호 해쉬를 제외한 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등에서 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬 등을 원문으로 보고, 이 원문을 해쉬한 것과 상기 사용자 전자서명값을 인증정보 내의 공개키로 복호화 것이 서로 일치되는 것인지를 확인하는 것이다. 이후, 인증정보의 전자서명 검증은 상기와 같다. 이후, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 보낸 사용자 아이디 및 난수와 서로 일치하지 않아 실패 시, 포털서버에서 해당 등록, 인증, 탈퇴를 최종적으로 실패처리 한 후에, 포털서버에서 상기 인증정보 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 임시 저장한 후에, 이 실패 메시지와 사용자 아이디를 사용자단말기로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 보낸 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 즉 등록, 인증, 탈퇴 성공시, 포털서버에서 상기 자신이 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔서 성공신호를 만든다. 이후, 포털서버에서 중계서버로 해당 성공신호를 shuffle 번호대로 shuffle 한 후에 https로 보내서 중계서버에서 보조인증을 받고, 해당 보조인증이 성공시에는 포털서버에서 해당 등록, 인증, 탈퇴를 최종적으로 성공처리하고, 포털서버에서 time limit이 있는 성공 토큰을 생성해서 이를 아이디와 함께 포털서버에 임시 저장한 후, 이 time limit이 있는 성공 토큰과 사용자 아이디를 포털서버에서 사용자단말기로 https를 활용해서 보낸다. 이와는 달리, 보조 인증이 실패 시에는 포털서버에서 해당 등록, 인증, 탈퇴를 최종적으로 실패처리 한 후에, 포털서버에서 사용자 아이디 및 실패 메시지를 임시 저장한 후에, 이 실패 메시지와 사용자 아이디를 포털서버에서 사용자단말기로 https를 활용해서 전송하는 기능과, 상기 사용자단말기에서 성공 시에는, 사용자 아이디, 웹 쿠기 또는 웹 세션아이디 그리고 상기 time limit 이 있는 성공토큰을, 실패 시에는 사용자 아이디, 웹 쿠키 또는 웹 세션아이디 그리고 상기 실패 메시지를 사용해서 고객사 웹 서버에게 사용자 아이디의 등록, 인증, 탈퇴의 최종 성공여부를 https로 물어보는 사용자단말기와; 포털서버가 중계서버로부터 등록 데이터를 https로 전송받고 포털서버에서 사용자 아이디, 난수, 이들의 해쉬값을 중계서버로 https를 활용해서 전송하는 기능과, 사용자단말기가 포털서버로 인증정보를 shuffle 해서 보내고 포털서버에서 shuffle 번호대로 원복 후에, 해당 인증정보를 전자서명 검증 한다. 이후, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버를 통해 사용자단말기기로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버에서 상기 인증정보 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 임시 저장한 후에, 이 실패 메시지와 사용자 아이디를 사용자단말기로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 중계서버를 통해 사용자단말기로 보낸 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 상기 포털서버가 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버에서 중계서버로 VPN 이나 https를 사용해서 shuffle 번호대로 shuffle 해서 전송하고, 이후, 포털서버가 중계서버로 VPN 이나 https를 활용해서 보낸 성공신호와 사용자단말기가 중계서버로 https를 활용해서 보내고 중계서버에 임시 저장된 인증정보를 중계서버에서 서로 비교해서, shuffle 번호와 shuffle 번호 해쉬를 제외하고 모두가 다 서로 일치하고 해당 성공신호에 해당되는 중계서버에서 사용자 최초 등록 시에 미리 저장된 등록데이터가 개인키 유출로 마킹된 것이 아니라면, 중계서버에서 상기 성공신호와 인증정보를 비교하는 보조인증을 성공으로 설정하고 중계서버에서 포털서버로 VPN 이나 https를 활용해서 상기 성공신호의 난수정보가 포함된 성공 메시지와 사용자 아이디를 보낸다. 이때, 성공 메시지는 성공 유무 정보, 사용자 아이디, 인증정보 또는 성공신호 내의 난수정보, 인증정보 또는 성공신호 내의 프로세스 정보, 및 기타 정보를 포함한다. 여기서, 기타 정보에는 해당 사고가 개인키 유출 사고의 등록, 인증, 탈퇴 시도인지, 해커의 다른 사용자의 다른 공개키 등록, 인증, 탈퇴 시도인지, 해커의 중계서버 우회 등록, 우회 인증, 우회 탈퇴 시도인지, 아니면 기타 성공인지를 설명한다. 이하, 성공 메시지는 상기와 같다. 또한, 중계서버에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에도 보조인증을 성공으로 설정하고 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이와 달리, 중계서버에서 사용자단말기가 중계서버로 보내고 임시 저장된 등록데이터가 사용자 최초 등록 시에 미리 저장되어 있고 개인키 유출로 마킹이 되어 있는 등록데이터와 일치하고, 상기 성공신호와 중계서버에 미리 임시 저장된 인증정보 및 중계서버에 미리 임시 저장된 등록데이터의 공개키 등이 아이디를 기준으로 서로 일치하면 해커가 유출된 개인키로 해킹하는 것으로 보고 해커의 개인키 유출 사고의 등록, 인증의 경우엔, 중계서버에서 포털서버로 VPN 이나 https를 활용해서 상기 성공신호의 난수정보가 포함된 실패 메시지와 사용자 아이디를 보낸다. 하지만, 중계서버에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 또한, 중계서버에서 성공신호와 인증정보를 사용자 아이디를 기준으로 비교해서 공개키 등이 서로 불일치할 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도로 보고 중계서버에서 포털서버로 VPN 이나 https를 활용해서 상기 성공신호의 난수정보가 포함된 실패 메시지와 사용자 아이디를 보낸다. 또한, 중계서버에서 성공신호가 있으나 해당 인증정보가 없다면 중계서버를 우회 등록, 우회 인증, 우회 탈퇴하려는 해킹 시도로 보고 중계서버에서 포털서버로 VPN 이나 https를 활용해서 상기 성공신호 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 보낸다. 이후, 포털서버에서 중계서버로부터 실패 메시지와 사용자 아이디를 받은 경우, 포털서버에서 사용자단말기로부터 받고 전자서명 검증된 인증정보를 가지고 해당 고객사 웹 서버 URL에서 개인키 유출 사고로 마킹된 공개키로 해커가 등록, 인증을 하려고 했거나, 또는 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도, 또는 해커가 중계서버를 우회 등록, 우회 인증, 또는 우회 탈퇴 하려는 시도로 보고 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고한다. 그리고, 상기에서 포털서버가 중계서버로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받은 경우, 포털서버에서 사용자단말기로부터 받은 전자서명 검증된 인증정보를 가지고 해당 고객사 웹 서버 URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 탈퇴를 할려고 하는 시도로 보고 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고한다. 이후, 포털서버에서 중계서버로부터 실패 메시지와 사용자 아이디를 받은 개인키 유출 사고의 등록, 인증의 경우 최종적으로 등록, 인증 취소를 하고, 이와는 달리, 중계서버로부터 성공메시지를 받은 개인키 유출 사고의 탈퇴의 경우, 즉, 사용자 자신이나 해커의 탈퇴의 경우 포털서버에서 해당 탈퇴를 최종적으로 진행한다. 이와는 달리, 포털서버에서 중계서버로부터 실패 메시지와 사용자 아이디를 받은 다른 공개키 등록, 인증, 탈퇴의 경우엔, 포털서버에서 최종적으로 등록, 인증, 탈퇴 취소를, 포털서버에서 중계서버로부터 실패 메시지와 사용자 아이디를 받은 중계서버 우회 해킹의 경우엔, 포털서버에서 최종적으로 우회 등록, 우회 인증, 우회 탈퇴를 취소한다. 이후, 포털서버가 중계서버로부터 성공 메시지와 사용자 아이디를 받은 경우, 포털서버에서 최종적으로 해당 등록, 인증, 탈퇴를 성공처리한다. 이후, 포털서버에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버에 임시 저장하고, 이 time limit 이 있는 성공 토큰과 사용자 아이디를 포털서버에서 사용자단말기로 https를 활용해서 보낸다. 반대로, 포털서버에서 중계서버로부터 실패 메시지와 사용자 아이디를 받은 경우, 포털서버에서 해당 사용자 아이디 및 상기 실패 메시지를 임시 저장하고, 이 사용자 아이디 및 실패 메시지를 포털서버에서 사용자단말기로 https를 활용해서 보내는 기능을 갖는 포털서버(SIDSL 서비스 서버)와; 상기 사용자단말기로부터 중계서버(relay server)로 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 https로 전송하고, 이후, 사용자의 최초 등록 시에는, 해당 등록데이터의 사용자 아이디(즉, 사용자 이메일 주소+지역번호) 내의 지역번호가 해당 중계서버와 맞지 않으면 프로세스를 중단하고, 이후, 해당 중계서버에서 등록데이터 내의 사용자 아이디의 유일성을 검증 후, 실패 시 프로세스를 중단하고, 이후, 중계서버에서 등록데이터의 전자서명을 검증한 후 저장하며, 실패 시 해당 등록데이터를 저장하지 않고 프로세스를 중단하는 기능과, 사용자의 최초 등록 이후의 등록 및 인증, 탈퇴 시 에는 중계서버에 미리 저장된 등록데이터와 사용자단말기가 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭이 되더라도 서로를 해쉬값으로 비교한 후 불일치 시 프로세스를 중단하고, 이후, 최초 사용자 등록 및 최초 사용자 등록 이후의 등록, 인증, 탈퇴 시에는 상기 사용자단말기로부터 받은 등록데이터를 중계서버에 임시 저장하는 기능과, 이후, 중계서버가 해당 등록 데이터를 포털서버로 https를 활용해서 보내고, 중계서버가 포털서버로부터 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송받고, 중계서버가 상기 사용자단말기로 상기 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송하는 기능과, 사용자단말기에서 중계서버로 인증정보인 shuffle 번호, suffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬값을 shuffle 번호대로 shuffle해서 https로 전송한 후, 중계서버에서 shuffle 번호대로 인증정보를 복원하는 기능과, 상기 복원 후, 인증정보 내의 원본과 원본의 해쉬값들에서 원본을 해쉬한 것들과 원본의 해쉬값들이 서로 일치하는 지 검증하고 하나라도 불일치 시 프로세스를 중단한다. 이후, 필요하다면 추가로, 중계서버에서 해당 인증정보의 전자서명을 검증하고 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 안해도 되는 기능과, 이 인증정보와 중계서버에 미리 임시 저장된 등록데이터와 비교시 아이디와 공개키가 불일치 시 프로세스를 중단한다. 이후에, 해당 인증정보를 중계서버에 임시 저장하는 기능과, 사용자단말기가 고객사 웹 서버로부터 최초 로그인 화면을 받을 시 사용자단말기가 고객사 웹 서버로부터 함께 받은 포털서버 URL 정보를 사용해서, 사용자단말기가 shuffle 번호대로 shuffle 된 상기 인증정보를 상기 포털서버 URL 정보에 해당되는 포털서버(SIDSL 서비스 서버)로 https를 사용해서 전송하고 포털서버에서 shuffle 번호대로 다시 복원에 성공한다. 이후, 복원에 실패 시, 즉, 복원된 인증정보 내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본을을 해쉬한 것들과 원본의 해쉬들을 서로 비교 시 하나라도 불일치 시, 프로세스를 중단한다. 이후, 해당 인증정보를 전자서명 검증 한다. 이후, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버를 통해 사용자단말기기로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버에서 상기 인증정보 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 임시 저장한 후에, 이 실패 메시지와 사용자 아이디를 사용자단말기로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 중계서버를 통해 사용자단말기로 보낸 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 상기 포털서버가 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버에서 중계서버로 shuffle 번호대로 shuffle 해서 VPN 이나 https를 활용해서 전송하고, 중계서버에서 shuffle 번호대로 복원한다. 복원 후, 인증정보 내의 원본과 원본의 해쉬값들에서 원본을 해쉬한 것들과 원본의 해쉬들이 서로 일치하는지 검증하고 하나라도 불일치 시 프로세스를 중단하는 기능과, 상기 성공신호에 해당되는 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 중계서버에 미리 임시 저장된 인증정보가 중계서버에 없을 경우 중계서버에서 포털서버로 상기 성공신호 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 포털서버에서 상기 실패 메시지와 사용자 아이디를 받았을 경우, 사용자단말기가 포털서버로 shuffle 번호대로 shuffle 해서 https로 보내고 전자서명 검증이된 인증정보의 고객사 웹 서버 URL 이 우회 등록, 우회 인증, 우회 탈퇴 당했다고 보고 포털서버에서 해당 사용자에게 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일 전송한 다음 포털서버에서 최종적으로 등록, 인증, 탈퇴를 취소하게 하는 기능과, 이와는 달리, 중계서버에서 성공신호에 해당되는 인증정보 및 해당 등록데이터가 있지만, 사용자 아이디 기준으로 공개키 등이 서로 불일치하는 경우, 중계서버를 활용해서 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹시도로 보고, 또한 중계서버에서 아이디를 기준으로 성공신호에 해당되는 임시 저장된 인증정보와 임시 저장된 등록데이터가 있고 사용자 아이디와 공개키 등이 서로 일치하지만, 임시 저장된 등록데이터에 해당되고 사용자가 최초 등록 시에 미리 저장한 등록데이터가 개인키 유출로 마킹된 것이라면, 해커가 유출된 개인키로 해킹하는 개인키 유출 사고로 본다. 이 두 경우 다 중계서버에서 포털사이트로 상기 성공신호내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 하지만, 중계서버에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버가 중계서버로부터 실패 메시지와 사용자 아이디를 받은 경우, 사용자단말기가 포털서버로 보내고 전자서명 검증된 해당 인증정보의 고객사 웹 서버 URL이 해킹된 것으로 보고, 즉, 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려고 하거나 개인키 유출 사고의 경우 해커가 유출된 개인키로 등록, 인증을 하려는 시도로 보고 사용자 아이디 내의 이메일 주소를 활용해서 각각의 사고 내용에 대한 이메일 전송을 포털서버에서 한다. 그리고, 포털서버가 중계서버로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받았을 경우, 사용자 자신이나 해커의 탈퇴 시도로 보고 사용자 아이디 내의 사용자 이메일 주소를 활용해서 각각 이메일 전송을 포털서버에서 한다. 이후, 포털서버에서 중계서버로부터 실패 메시지와 사용자 아이디를 받은 다른 사용자 아이디의 다른 공개키 등록, 인증, 탈퇴의 경우엔, 최종적으로 등록, 인증, 탈퇴 취소를 하고, 포털서버에서 중계서버로부터 실패 메시지와 사용자 아이디를 받은 개인키 유출 사고의 등록, 인증의 경우 최종적으로 등록, 인증 취소를 하고, 포털서버에서 중계서버로부터 성공 메시지와 사용자 아이디를 받은 개인키 유출 사고의 탈퇴의 경우, 즉 개인키 유출 사고의 사용자 자신 또는 해커의 탈퇴의 경우 포털서버에서 해당 탈퇴를 최종적으로 진행한다. 이와는 달리, 상기 포털서버가 중계서버에게 shuffle 번호대로 shuffle해서 VPN 이나 https로 보내고 중계서버에서 shuffle 번호대로 복원에 성공한 성공신호와 해당 성공신호에 해당되는 사용자단말기가 중계서버로 shuffle 번호대로 shuffle 해서 https로 보내고 중계서버에서 shuffle 번호대로 복원에 성공한 후에 중계서버에 미리 임시 저장된 인증정보가 있고, 상기 성공신호와 상기 인증정보가 서로 shuffle 번호와 shuffle 번호 해쉬를 제외하고 일치할 경우, 그리고, 사용자 아이디를 기준으로 상기 성공신호에 해당되고 중계서버에서 사용자의 최초 등록 시 미리 저장된 등록데이터가 개인키 유출로 마킹된 경우가 아니라면, 보조인증을 성공으로 보고, 중계서버가 받은 상기 성공신호 내의 난수가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버에서 중계서버로부터 성공 메시지와 사용자 아이디를 받으면 최종적으로 등록, 인증, 탈퇴를 성공으로 처리한다. 하지만, 상기 성공신호 전에 사용자단말기가 중계서버로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기가 중계서버에 보낸 인증정보의 아이디와 공개키가 상기 미리 임시 저장된 등록데이터와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키가 서로 일치하는 후자의 경우엔 중계서버에서 사용자단말기로부터 받은 인증정보 내의 해당 고객사 웹 서버 URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 등록 또는 인증을 하려고 하는 시도로 보고, 중계서버에서 상기 인증정보 내의 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만, 개인키 유출 사고의 탈퇴의 경우 해당 프로세스를 중계서버에서 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디 별 공개키 등이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)로 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디 별 공개키가 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디 별 공개키가 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단하고, 개인키 유출로 중계서버에서 해당 사용자의 등록데이터 안의 공개키가 마킹되었을 시에만, 해당 사용자가 자신의 아이디와 자신의 새로운 공개키를 가지고, 본 문서에 기록된 대로, 최초 등록 시에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터의 저장 및 정상적으로 등록 진행, 그리고 최초 등록 이후에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터 및 인증정보를 가지고 등록, 인증, 탈퇴를 정상으로 진행한다. 이후, 최초 등록 시 및 최초 등록 이후의 두 경우 다, 포털서버에서 중계서버로부터 보조인증의 결과를 받고, 고객사 웹 서버가 로그인의 성공 유무를 포털서버로 물어보고, 해당 고객사 웹 서버가 사용자단말기로 성공 시 성공화면을 실패 시 실패 화면을 전송하는 마지막 끝까지 해당 사용자의 등록, 인증, 탈퇴를 사용자의 새로운 공개키로 정상적으로 진행 할 수 있는 기능을 갖는 중계서버; 을 포함함을 특징으로 한다.

상기 본 발명에 있어서, 상기 중계서버에서 사용자단말기가 중계서버로 보낸 등록데이터 및 인증정보의 경우, 포털서버가 중계서버로 준 성공신호와 사용자단말기가 중계서버로 준 인증정보가 아이디를 기준으로 비교될 때 까지만 상기 등록데이터 및 상기 인증정보를 중계서버에서 임시 저장하고, 중계서버에서 상기 성공신호와 상기 인증정보가 아이디를 기준으로 비교된 후에는, 상기 등록데이터와 상기 인증정보를 중계서버에서 삭제하는 것을 더 포함함을 특징으로 한다.

상기 본 발명에 있어서, 상기 사용자단말기에서 포털서버로 인증정보를 shuffle 번호대로 shuffle해서 https로 전송한 후, 포털서버에서 shuffle 번호대로 복원에 성공한 후에 해당 인증정보를 전자서명 검증 후에, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 중계서버를 통해 사용자단말기로 보낸 아이디 및 난수와 서로 일치하지 않아 실패 시, 포털서버에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버에서 상기 인증정보 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 임시 저장한 후에, 이 실패 메시지와 사용자 아이디를 사용자단말기로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 중계서버를 통해 사용자단말기로 보낸 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 상기 인증정보에서 shuffle 번호와 shuffle 번호해쉬 만 바꿔서 성공신호를 만들고 이 성공신호를 shuffle 번호대로 shuffle 해서 VPN 이나 https를 활용해서 중계서버로 보낸다. 이후, 중계서버에서 shuffle 번호대로 복원에 성공한 성공신호와 이에 해당되는 인증정보를 서로 비교해서 shuffle 번호, shuffle 번호 해쉬를 제외하고 서로 일치하고, 중계서버가 이미 사용자 최초 등록 시에 미리 저장해서 가지고 있고 사용자 아이디를 기준으로 상기 성공신호에 해당하는 등록데이터가 개인키 유출로 마킹된 것이 아니라면, 보조인증을 성공으로 보고, 중계서버에서 포털서버로 상기 성공신호에 있는 난수를 포함한 성공 메시지와 아이디를 VPN 이나 https를 활용해서 보낸다. 이와는 달리, 상기 성공신호와 인증정보의 공개키 등을 포함한 비교가 서로 맞지 않아 해커의 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보거나, 상기 성공신호와 인증정보의 난수를 포함한 비교가 서로 일치해도 성공신호의 사용자 아이디와 공개키가 개인키 유출로 마킹되고 사용자 최초 등록 시에 중계서버에 미리 저장된 해당 등록데이터의 사용자 아이디 및 공개키와 일치된다면 이를 개인키 유출사고로 보거나, 또는 상기 성공신호에 해당되는 인증정보가 없어 해커의 중계서버를 우회한 등록, 인증, 탈퇴의 시도로 볼 경우에는, 모두 다 보조인증 실패로 보고, 상기 성공신호에 있는 난수가 포함된 실패 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 하지만, 중계서버에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버에서 중계서버로부터 성공 메시지와 사용자 아이디를 받은 경우, 즉, 보조인증 성공으로 정의한 개인키 유출 사고의 사용자 자신이나 해커의 탈퇴의 경우나 나머지 중계서버의 보조인증 성공의 경우엔, 전자의 경우, 포털서버가 사용자단말기로부터 받고 전자서명 검증된 인증정보내의 고객사 웹 서버 URL에서 개인키 유출 사고의 탈퇴가 발생한 것으로 보고 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴를 상기 인증정보 내의 사용자 아이디 내의 이메일 주소를 사용해서 이메일로 포털서버에서 전송한다. 후자의 경우, 아무런 이메일 전송이 없다. 이후, 포털서버에서 해당 등록, 인증, 탈퇴를 최종적으로 성공 처리한다. 이후, 포털서버에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버에 임시 저장한 후에, 이 사용자 아이디와 time limit 이 있는 성공 토큰을 포털서버에서 사용자단말기로 https를 활용해서 보내주고, 포털서버가 중계서버로부터 실패 메시지와 아이디를 받았을 시에는, 즉, 개인키 유출 사고의 등록, 인증이나, 해커의 다른 사용자 아이디의 다른 공개키 등록, 인증, 탈퇴, 또는 해커의 중계서버를 우회 등록, 우회 인증, 우회 탈퇴하는 해킹 시도로 보고, 해당 사고 내용을 포털서버가 사용자단말기로부터 받고 전자서명 검증된 인증정보 내의 고객사 웹 서버 URL의 정보를 포함해서 해당 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 전송한다. 이후, 포털서버에서 해당 등록, 인증, 탈퇴를 최종적으로 실패 처리한다. 이후, 사용자 아이디와 상기 실패 메시지를 포털서버에 임시 저장하고, 이 사용자 아이디와 실패 메시지를 사용자단말기기로 https를 활용해서 보내준다. 하지만, 상기 성공신호 전에 사용자단말기가 중계서버로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기가 중계서버에 보낸 인증정보 내의 사용자 아이디와 공개키가 상기 미리 임시 저장된 등록데이터와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키가 서로 일치하는 후자의 경우엔 중계서버에서 사용자단말기로부터 받은 인증정보 내의 해당 고객사 웹 서버 URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 등록 또는 인증을 하려고 하는 시도로 보고, 중계서버에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만 ,개인키 유출 사고의 탈퇴의 경우, 등록데이터끼리 일치하는 전자의 경우에는 중계서버에서 해당 프로세스를 그냥 진행하고, 등록데이터와 인증정보가 일치하는 후자의 경우에 있어서도 중계서버에서 해당 프로세스를 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디 별 공개키들이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디 별 공개키가 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디 별 공개키가 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 중계서버가 받은 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단하고, 개인키 유출로 중계서버에서 해당 사용자의 등록데이터 안의 공개키가 마킹되었을 시에만, 해당 사용자가 자신의 아이디와 자신의 새로운 공개키를 가지고, 본 문서에 기록된 대로, 최초 등록 시에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터의 저장 및 정상적으로 등록 진행, 그리고 최초 등록 이후에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터 및 인증정보를 가지고 등록, 인증, 탈퇴를 정상으로 진행한다. 이후, 최초 등록 시 및 최초 등록 이후의 두 경우 다, 포털서버에서 중계서버로부터 보조인증의 결과를 받고, 고객사 웹 서버가 로그인의 성공 유무를 포털서버로 물어보고, 해당 고객사 웹 서버가 사용자단말기로 성공 시 성공화면을 실패 시 실패 화면을 전송하는 마지막 끝까지 해당 사용자의 등록, 인증, 탈퇴를 사용자의 새로운 공개키로 정상적으로 진행 할 수 있다. 이후, 해당 사용자단말기는 해당 고객사 웹 서버에게 자신이 최초 로그인 화면에서 받은 웹 쿠키 또는 웹 세션아이디 및 상기 포털서버로부터 받은 사용자 아이디 및 성공 시에는 상기 time limit 이 있는 성공 토큰을, 실패 시에는 상기 실패 메시지를 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버에 문의한다. 이후, 고객사 웹 서버는 해당 사용자 아이디를 포털서버에 문의하고, 성공 시에는 사용자 아이디와 time limit이 있는 성공 토큰을 고객사 웹 서버가 포털서버로부터 가져오고, 실패 시에는 사용자 아이디와 실패 메시지를 고객사 웹 서버가 포털서버로부터 가져와서, 사용자단말기가 고객사 웹 서버에게 준 time limit 이 있는 성공 토큰과 고객사 웹 서버가 포털서버로부터 가져온 time limit이 있는 성공 토큰의 비교가 일치해서 성공 시에는 최종 성공을, 나머지의 경우에는 최종 실패를 결정하고 최종 성공 시 성공화면을 최종 실패 시 실패화면을 고객사 웹 서버가 사용자단말기로 https로 전송하는 것을 특징으로 한다.

상기 본 발명에 있어서, 상기 포털서버와 중계서버를 활용해서 개인키 유출 사고 대응 및 이메일 대응, 중계서버 우회 등록, 우회 인증, 우회 탈퇴 대응 및 이메일 대응, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 대응 및 이메일 대응을 할 수 있는 것을 포함함을 특징으로 한다.

또한, 상기 목적을 달성하기 위한 본 발명의 바람직한 일실시예에 따른 포털사이트 중계 서비스 제공 방법에 있어서, 등록 과정은 고객사 웹 서버에서 사용자단말기로 고객사의 로그인 화면이 디스플레이 되게 하고, 해당 화면이 디스플레이 되면서 해당 고객사 웹 서버에서 해당 사용자단말기로 고객사 웹 서버 URL 정보와 고객사 웹 서버가 전용으로 사용하는 포털서버의 포털서버 URL 정보들을 같이 전송하는 단계(a)와; 상기 사용자단말기에서 중계서버(relay server)로 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 https로 전송하고, 이후, 사용자의 최초 등록 시에는, 상기 등록데이터의 사용자 아이디(즉, 사용자의 이메일 주소+지역번호) 내의 지역번호가 해당 중계서버와 맞지 않으면 프로세스를 중단하고, 이후, 중계서버에서 등록데이터 내의 사용자 아이디의 유일성을 검증 후, 실패 시 프로세스를 중단하고, 이후, 중계서버에서 등록데이터의 전자서명을 검증한 후 저장하며, 실패 시 해당 등록데이터를 저장하지 않고 프로세스를 중단하며, 사용자의 최초 등록 이후의 등록 및 인증, 탈퇴 시 에는 중계서버에 미리 저장된 등록데이터와 사용자단말기가 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭이 되더라도 서로를 해쉬해서 비교한 후 일치하는 것이 없을 시 프로세스를 중단하고, 이후, 최초 사용자 등록 및 최초 사용자 등록 이후의 등록, 인증, 탈퇴에서 해당 등록데이터를 중계서버에 임시 저장하는 단계(b)와; 상기 중계서버에서 포털서버로 등록 데이터를 https로 전송하는 단계(c)와; 상기 포털서버에서 사용자 아이디, 난수, 이들의 해쉬 값을 중계서버로 https를 활용해서 전송하는 단계(d)와; 상기 중계서버에서 사용자단말기로 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송하는 단계(e)와; 상기 사용자단말기에서 중계서버로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값을 shuffle 번호대로 shuffle 해서 https로 전송하고, 중계서버에서 shuffle 번호에 따라 복원하고, 복원 이후에는, 인증정보 내의 각각의 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들이 하나라도 불일치 시 프로세스를 중단한 후, 중계서버에서 필요하다라면 추가로 해당 인증정보의 전자서명을 검증하고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 해당 인증정보를 검증하지 않아도 된다. 이후 인증정보와 중계서버에 미리 임시 저장된 등록데이터와 비교시 사용자 아이디별 공개키들이 불일치 시 프로세스를 중단한다. 이후, 해당 인증정보를 중계서버에 임시 저장하는 단계(f)와; 상기 사용자단말기가 고객사 웹 서버로부터 최초 로그인 화면을 받을 시 사용자단말기가 고객사 웹 서버로부터 함께 받은 포털서버 URL 정보를 사용해서, 사용자단말기가 shuffle 번호대로 shuffle 된 상기 인증정보를 상기 포털서버 URL 정보에 해당되는 포털서버(SIDSL 서비스 서버)로 https를 사용해서 전송하는 단계(g)와; 사용자단말기가 포털서버에 보내고 포털서버에서 shuffle 번호대로 복원된 해당 인증정보를 전자서명 검증 후에, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보의 사용자 아이디와 난수 데이터가 포털서버 자신이 보낸 사용자 아이디 및 난수와 서로 일치하지 않아 실패 시, 포털서버에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버에서 상기 인증정보 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 임시 저장한 후에, 이들을 사용자단말기로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 사용자단말기로 보낸 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 상기 포털서버가 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버에서 중계서버로 shuffle 번호대로 shuffle 해서 VPN 이나 https를 활용해서 전송하고, 이후 중계서버에서 shuffle 번호에 따라 다시 복원한 후, 성공신호 안에 있는 원본과 원본의 해쉬들에서 원본들을 해쉬한 것들과 원본의 해쉬들이 하나라도 서로 불일치 시 프로세스를 중단하는 단계(h)와; 상기 중계서버에서 성공신호에 해당되는 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 중계서버에 미리 임시 저장된 인증정보가 없을 경우 중계서버에서 포털서버로 상기 성공신호내에 있는 난수 정보가 포함된 실패 메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 포털서버에서 상기 실패 메시지 및 아이디를 받은 경우, 사용자단말기가 포털서버로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버 URL이 해커가 중계서버를 쓰지 않는 우회 등록, 우회 인증, 우회 탈퇴 해킹당했다고 보고, 포털서버에서 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 해커의 중계서버 우회 등록, 우회 인증, 우회 탈퇴를 전송한다. 이후, 사용자단말기로부터 포털서버로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버 URL이 해커가 중계서버를 쓰지 않는 우회 등록, 우회 인증, 우회 탈퇴 해킹당했다고 보고 해당 포털서버에서 최종적으로 우회 등록, 우회 인증, 우회 탈퇴를 취의하는 단계(i)와; 상기 중계서버에서 포털서버가 중계서버로 shuffle 번호대로 shuffle해서 VPN 이나 https를 활용해서 보내고 중계서버에서 shuffle 번호대로 원복에 성공한 성공신호와 사용자단말기가 이전에 중계서버로 shuffle 번호대로 shuffle해서 https로 보내고 중계서버에서 shuffle 번호대로 복원에 성공하고 중계서버에 미리 임시 저장된 인증정보의 공개키 등이 사용자 아이디를 기준으로 서로 불일치하는 경우, 중계서버를 활용해서 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹시도로 보고, 중계서버에서 아이디를 기준으로 성공신호에 해당되는 임시 저장된 인증정보와 임시 저장된 등록데이터가 있고 shuffle 번호 및 shuffle 번호 해쉬를 제외하고 상기 성공신호와 해당 중계서버에 임시 저장된 인증정보가 서로 일치하지만, 사용자 아이디를 기준으로 상기 성공신호에 해당되고 사용자가 최초 등록 시에 미리 저장한 등록데이터가 개인키 유출로 마킹된 것이라면, 해커나 사용자 자신이 유출된 개인키로 해킹하는 개인키 유출 사고로 본다. 이 두 경우 다 중계서버가 포털서버로 성공신호내에 있는 난수 정보가 포함된 실패 메시지와 아이디를 VPN 이나 https를 활용해서 보낸다. 하지만, 중계서버에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 여기서 난수정보를 활용하는 이유는 replay 공격을 막기 위해서이다. 이후, 포털서버에서 중계서버로부터 실패 메시지를 받은 경우, 포털서버에서 사용자단말기로부터 자신이 받고 전자서명 검증된 인증정보의 고객사 웹 서버 URL이 해킹된 것으로 보고, 포털서버에서 이메일로 해당 사용자에게 아이디 내의 이메일 주소를 활용해서 사고 내용, 즉, 다른 공개키의 등록 시도 및 개인키 유출 사고의 등록 시도를 전송한다. 이후, 포털서버에서 사용자단말기로부터 자신이 받고 포털서버에서 전자서명 검증된 인증정보의 고객사 웹 서버 URL이 해킹된 것으로 보고 포털서버에서 다른 공개키 등록, 인증, 탈퇴의 경우 최종적으로 등록 취소를 개인키 유출의 등록, 인증의 경우 최종적으로 등록 취소를 한다. 하지만, 개인키 유출 사고에서 사용자 자신 또는 해커의 탈퇴의 경우, 보조인증을 성공으로 보고, 포털서버가 중계서버로부터 성공 메시지와 사용자 아이디를 받고 포털서버에서 사용자단말기로부터 자신이 받고 전자서명 검증된 인증정보의 고객사 웹 서버 URL이 해킹된 것으로 보고, 포털서버에서 이메일로 해당 사용자에게 아이디 내의 이메일 주소를 활용해서 사고 내용, 즉, 개인키 유출 사고의 탈퇴 시도를 전송한다. 이후, 포털서버에서 해당 탈퇴를 최종적으로 진행하는 단계(j)와; 상기 중계서버에서 상기 성공신호와 상기 성공신호에 해당하는 중계서버에 미리 임시 저장된 인증정보를 서로 비교해서 shuffle 번호와 shuffle 번호 해쉬를 제외하고 서로 일치하고 해당 성공신호에 해당되고 중계서버에서 사용자의 최초 등록 시 미리 저장된 등록데이터가 개인키 유출로 마킹된 것이 아니라면, 즉, 보조인증이 성공이라면 중계서버에서 포털서버로 VPN 이나 https를 활용해서 상기 성공신호내에 있는 난수정보가 포함된 성공 메시지와 아이디를 전송한다. 또한, 중계서버에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에도, 보조인증 성공으로 보고 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이와는 달리, 상기 성공신호와 이 성공신호에 해당하는 중계서버에서 임시 저장된 해당 인증정보 및 중계서버에 임시 저장된 해당 등록데이터를 서로 비교해서 보조 인증이 실패 시, 즉, 상기 개인키 유출 사고 시 해커의 등록, 인증의 경우, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도, 및 해커의 중계서버를 우회하는 우회 등록, 우회 인증, 우회 탈퇴의 경우에는 상기 성공신호 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버에서 중계서버로부터 성공 메시지와 사용자 아이디를 받았을 시에는, 즉, 보조인증 성공 중의 하나인 개인키 유출 사고의 탈퇴의 경우와 중계서버에서의 나머지 보조 인증이 성공 시에는, 전자의 경우, 사용자단말기로부터 포털서버가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버 URL에서 사용자나 해커가 개인키 유출 사고의 탈퇴를 하는 것으로 보고, 인증정보 내의 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 해당 사용자에게 사고 내용을 포털서버에서 전송한다. 후자의 경우, 포털서버에서 아무런 이메일 대응이 없다. 이후, 포털서버에서 해당 등록을 최종적으로 성공처리한다. 이후, 포털서버에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버에 임시 저장하고, 이 time limit이 있는 성공 토큰과 사용자 아이디를 각각 포털서버에서 사용자단말기로 https를 활용해서 전송한다. 하지만 반대로, 포털서버에서 중계서버로부터 실패 메시지를 받았을 시에는, 즉, 개인키 유출 사고의 등록 및 인증의 경우, 해커의 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도, 또는 해커가 중계서버를 우회해서 우회 등록, 우회 인증, 우회 탈퇴 하려는 시도일 경우, 사용자단말기로부터 포털서버가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버 URL에서 사용자의 아이디 내의 사용자의 이메일 주소를 활용해서 상기 해당 사고 내용, 즉 개인키 유출 사고의 등록 시도, 해커의 다른 사용자 아이디로 다른 공개키를 등록하려는 시도, 해커가 중계서버를 우회해서 우회 등록하려는 시도를 이메일로 전송한다. 이후, 포털서버에서 해당 등록을 최종적으로 실패처리한다. 이후, 포털서버에서 사용자 아이디와 상기 실패 메시지를 임시 저장하고, 이 실패 메시지와 사용자 아이디를 각각 포털서버에서 사용자단말기로 https를 활용해서 전송한다. 하지만, 상기 성공신호 전에 사용자단말기가 중계서버로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기가 중계서버에 보낸 인증정보의 아이디와 공개키가 상기 미리 임시 저장된 등록데이터와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키가 서로 일치하는 후자의 경우엔 중계서버에서 사용자단말기로부터 받은 인증정보 내의 해당 고객사 웹 서버 URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 등록을 하려고 하는 시도로 보고, 중계서버에서 상기 인증정보 내의 사용자 아이디 내의 , 즉 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만, 개인키 유출 사고의 탈퇴의 경우, 해당 프로세스를 중계서버에서 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키들이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키들이 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디 별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단하고, 개인키 유출로 중계서버에서 해당 사용자의 등록데이터 안의 공개키가 마킹되었을 시에만, 해당 사용자가 자신의 아이디와 자신의 새로운 공개키를 가지고, 본 문서에 기록된 대로, 최초 등록 시에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터의 저장 및 정상적으로 등록 진행, 그리고 최초 등록 이후에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터 및 인증정보를 가지고 등록, 인증, 탈퇴를 정상으로 진행한다. 이후, 최초 등록 시 및 최초 등록 이후의 두 경우 다, 포털서버에서 중계서버로부터 보조인증의 결과를 받고, 고객사 웹 서버가 로그인의 성공 유무를 포털서버로 물어보고, 해당 고객사 웹 서버가 사용자단말기로 성공 시 성공화면을 실패 시 실패 화면을 전송하는 마지막 끝까지 해당 사용자의 등록, 인증, 탈퇴를 사용자의 새로운 공개키로 정상적으로 진행 할 수 있다.

이때, 중계서버에서 상기 성공신호와 중계서버에 미리 임시 저장된 인증정보와 중계서버에 미리 임시 저장된 등록데이터와의 비교를 실행 후에는, 중계서버에서 임시 저장된 해당 인증정보 및 중계서버에 임시 저장된 해당 등록데이터를 중계서버에서 삭제하는 단계(k)와; 상기 사용자단말기는 해당 고객사 웹 서버에게 자신이 최초 로그인 화면에서 받은 웹 쿠키나 웹 세션아이디 및 상기 포털서버로부터 받은 사용자 아이디와 성공 시에는 역시 상기 포털서버로부터 받은 time limit 이 있는 성공 토큰을, 실패 시에는 역시 상기 포털서버로부터 받은 상기 실패 메시지를 https로 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버에 https로 문의한다. 이후, 고객사 웹 서버는 해당 사용자 아이디를 포털서버에게 https로 문의하고 해당 사용자 아이디에 해당되는 상기 time limit이 있는 성공 토큰이나 실패 메시지를 사용자 아이디와 함께 고객사 웹 서버가 포털서버로부터 https를 활용해서 가져온다. 이후, 포털서버에서 포털서버에 임시 저장된 상기 time limit 이 있는 성공 토큰이나 사용자 아이디 및 실패 메시지나 사용자 아이디를 삭제한다. 이후, 사용자단말기가 고객사 웹 서버에게 https로 준 성공 토큰이 고객사 웹 서버가 포털서버로부터 https를 활용해서 가져온 성공 토큰과 비교가 일치해서 성공 시에는 최종 성공을, 나머지의 경우에는 최종 실패를 결정하고 최종 성공 시 성공화면을 최종 실패 시 실패화면을 https로 고객사 웹 서버가 사용자단말기에게 전송한다. 이후, 고객사 웹 서버에서 등록 성공 시, 고객사 웹 서버에서 고객사 웹 서버 전용 아이디와 본 기술의 사용자 아이디를 매칭시켜 고객사 웹 서버 DB에 이 매칭된 정보들을 저장하는 단계(l); 을 포함함을 특징으로 한다.

또한, 상기 목적을 달성하기 위한 본 발명의 바람직한 일실시 예에 따른 포털사이트 중계 서비스 제공 방법에 있어서, 인증 및 탈퇴 과정은 고객사 웹 서버에서 사용자단말기로 고객사의 로그인 화면이 디스플레이 되게 하고, 해당 화면이 디스플레이 되면서 해당 고객사 웹 서버에서 해당 사용자단말기로 고객사 웹 서버 URL 정보와 고객사 웹 서버가 전용으로 사용하는 포털서버의 포털서버 URL 정보들을 같이 전송하는 하는 단계(a)와; 상기 사용자단말기에서 중계서버(relay server)로 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 https로 전송하고, 중계서버가 받은 상기 등록데이터를 기존 사용자의 최초 등록단계에서 저장한 등록데이터와 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭이 되더라도 서로를 해쉬한 값으로 비교한 후 일치하는 등록데이터가 없는 경우 프로세스를 중단하고, 이후, 최초 사용자 등록 및 최초 사용자 등록 이후의 등록, 인증, 탈퇴 시에는 상기 사용자단말기로부터 받은 등록데이터를 중계서버에 임시 저장하는 단계(b)와; 상기 중계서버에서 포털서버로 등록 데이터를 https로 전송하는 단계(c)와; 상기 포털서버에서 사용자 아이디, 난수, 이들의 해쉬 값을 중계서버로 https를 활용해서 전송하는 단계(d)와; 상기 중계서버에서 사용자단말기로 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송하는 단계(e)와; 상기 사용자단말기에서 중계서버로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값을 shuffle 번호대로 shuffle 해서 https로 전송한 후, 중계서버에서 shuffle 번호대로 다시 복원 후에, 해당 인증정보 내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 하나라도 서로 불일치 시, 프로세스를 중단한단. 이후, 중계서버에서 필요시에는 추가로 해당 인증정보의 전자서명을 검증하고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명 검증을 하지 않아도 된다. 이후, 인증정보와 중계서버에 미리 임시 저장된 등록데이터를 비교시 아이디별 공개키들이 서로 불일치 시 프로세스를 중단한다. 이후에, 해당 인증정보를 중계서버에 임시 저장하는 단계(f)와; 상기 사용자단말기가 고객사 웹 서버로부터 최초 로그인 화면을 받을 시 사용자단말기가 고객사 웹 서버로부터 함께 받은 포털서버 URL 정보를 사용해서, 사용자단말기가 shuffle 번호대로 shuffle 된 상기 인증정보를 상기 포털서버 URL 정보에 해당되는 포털서버(SIDSL 서비스 서버)로 https를 사용해서 전송하는 단계(g)와; 상기 포털서버에서 사용자단말기가 포털서버에게 보낸 후 shuffle 번호대로 복원에 성공한 인증정보를 전자서명 검증 후에, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버를 통해 사용자단말기기로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버에서 상기 인증정보 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 임시 저장한 후에, 이 실패 메시지와 사용자 아이디를 사용자단말기로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 중계서버를 통해 사용자단말기로 보낸 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 상기 포털서버가 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버에서 중계서버로 shuffle 번호대로 shuffle 한 후 VPN 이나 https를 활용해서 전송하고, 중계서버에서 shuffle 번호대로 다시 복원한 후, 복원된 성공신호 내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 하나라도 서로 불일치 시, 프로세스를 중단하는 단계(h)와; 상기 중계서버에서 성공신호에 해당되는 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 중계서버에서 미리 임시 저장된 인증정보가 없을 경우 중계서버에서 포털서버로 성공신호내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 포털서버에서 중계서버로부터 상기 실패 메시지와 사용자 아이디를 받고 나서, 사용자단말기로부터 포털서버로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버 URL이 해커의 중계서버을 사용하지 않는 우회 등록, 우회 인증, 우회 탈퇴 해킹 시도를 당했다고 보고, 포털서버에서 중계서버를 우회해서 해킹한 우회 등록, 우회 인증, 우회 탈퇴 등의 해킹 사고 내용을 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 전송한다. 이후, 사용자단말기로부터 포털서버로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버 URL이 중계서버 우회 등록, 우회 인증, 우회 탈퇴 해킹당했다고 보고 포털서버에서 최종적으로 우회 등록, 우회 인증, 우회 탈퇴를 취소하는 단계(i); 상기 중계서버에서의 성공신호에 해당되는 중계서버에 미리 임시 저장된 인증정보 및 중계서버에 미리 임시 저장된 해당 사용자의 등록데이터가 있지만, 사용자 아이디별 공개키들이 서로 불일치하는 경우, 중계서버를 활용해서 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹시도로 보고, 중계서버에서 아이디를 기준으로 성공신호에 해당되는 임시 저장된 인증정보와 임시 저장된 등록데이터가 있고 사용자 아이디와 공개키 등이 서로 일치하지만, 임시 저장된 등록데이터에 해당되고 사용자가 최초 등록 시에 미리 저장한 등록데이터가 개인키 유출로 마킹된 것이라면, 해커가 유출된 개인키로 해킹하는 개인키 유출 사고로 본다. 이 두 경우 다, 중계서버에서 포털서버로 상시 성공신호내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 VPN 이나 https를 활용해서 보낸다. 하지만, 중계서버에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버가 중계서버로부터 실패 메시지와 사용자 아이디를 받은 경우, 사용자단말기로부터 포털서버로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버 URL이 해킹당했다고 보고 해당 사용자에게 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 다른 공개키의 인증, 탈퇴 시도 및 개인키 유출 사고 시 해커의 인증 시도를 전송한다. 그리고, 포털서버가 중계서버로부터 개인키 유출 사고 탈퇴 시의 성공 메시지와 사용자 아이디를 받은 경우, 사용자단말기로부터 포털서버로 보내고 전자서명 검증된 인증정보의 내의 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 개인키 유출 사고 시 사용자 자신이나 해커의 탈퇴 시도를 전송한다. 이후, 포털서버가 중계서버로부터 실패 메시지와 사용자 아이디를 받은 경우, 사용자단말기가 포털서버로 보내고 전자서명검증된 인증정보의 고객사 웹 서버 URL이 해킹된 것으로 보고, 해당 포털서버에서 다른 공개키 등록, 인증, 탈퇴의 경우 해당 인증, 탈퇴를 최종적으로 취소하고 개인키 유출 사고 시 해커의 등록, 인증의 경우 해당 인증을 최종적으로 취소한다. 하지만, 상기에서 포털서버가 중계서버로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받은 경우, 즉, 개인키 유출 사고에서 사용자 자신 또는 해커의 탈퇴의 경우, 포털서버에서 해당 탈퇴를 최종적으로 진행하는 단계(j)와; 상기 중계서버에서 상기 성공신호와 상기 성공신호에 해당하는 중계서버에 미리 임시 저장된 인증정보를 서로 비교해서 shuffle 번호와 shuffle 번호 해쉬를 제외하고 서로 일치하고 해당 성공신호에 해당되고 중계서버에서 사용자 최초 등록 시에 미리 저장된 등록데이터가 개인키 유출로 마킹된 것이 아니라면, 보조인증 성공으로 보고, 중계서버에서 포털서버로 VPN 이나 https를 활용해서 상기 성공신호내에 있는 난수정보가 포함된 성공 메시지와 사용자 아이디를 보낸다. 이때, 중계서버에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에도 보조인증 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이와는 달리, 상기 성공신호와 이 성공신호에 해당하는 중계서버에 미리 임시 저장된 인증정보 및 이 성공신호에 해당되고 중계서버에서 미리 임시 저장된 등록데이터를 서로 비교해서 보조 인증이 실패 시, 즉, 상기 개인키 유출 사고 시 해커의 등록 및 인증 시도, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도, 및 해커의 중계서버를 우회하는 우회 등록, 우회 인증, 우회 탈퇴의 경우에는 상기 성공신호 내의 난수정보가 포함된 실패 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버에서 중계서버로부터 성공 메시지와 사용자 아이디를 받았을 시에는, 즉, 보조인증 성공 중에 하나인 개인키 유출 사고의 탈퇴의 경우와 중계서버의 나머지 보조 인증들의 성공 시에는, 전자의 경우, 사용자단말기로부터 포털서버가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버 URL에서 사용자나 해커가 개인키 유출 사고의 탈퇴를 하는 것으로 보고 인증정보 내의 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 해당 사용자에게 사고 내용을 포털서버에서 전송한다. 후자의 경우, 포털서버에서 아무런 이메일 대응이 없다. 이후, 포털서버에서 해당 인증, 탈퇴를 최종적으로 성공처리 한다. 이후, 포털서버에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버에 임시 저장하고, 이 time limit이 있는 성공 토큰과 사용자 아이디를 각각 포털서버에서 사용자단말기로 https를 활용해서 전송한다. 하지만 반대로, 포털서버에서 중계서버로부터 실패 메시지와 사용자 아이디를 받았을 시에는, 즉, 개인키 유출 사고의 등록 및 인증의 경우, 해커의 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도, 또는 해커가 중계서버를 우회해서 우회 등록, 우회 인증, 우회 탈퇴 하려는 시도일 경우, 사용자단말기로부터 포털서버가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버 URL이 해킹당했다고 보고 해당 인증정보 내의 사용자의 아이디 내의 사용자 이메일 주소를 활용해서 상기 해당 사고 내용을 이메일로 전송한다. 이후, 포털서버에서 해당 인증, 탈퇴를 최종적으로 실패처리한다. 이후, 포털서버에서 사용자 아이디와 상기 실패 메시지를 임시 저장하고, 이 실패 메시지와 사용자 아이디를 각각 포털서버에서 사용자단말기로 https를 활용해서 전송한다. 하지만, 상기 성공신호 전에 사용자단말기가 중계서버로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기가 중계서버에 보낸 인증정보의 아이디와 공개키가 상기 미리 임시 저장된 등록데이터와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키가 서로 일치하는 후자의 경우엔 중계서버에서 사용자단말기로부터 중계서버가 받은 인증정보 내의 해당 고객사 웹 서버 URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 인증을 하려고 하는 시도로 보고, 중계서버에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만, 개인키 유출 사고의 탈퇴의 경우 해당 프로세스를 중계서버에서 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키들이 서의 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키가 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단하고, 개인키 유출로 중계서버에서 해당 사용자의 등록데이터 안의 공개키가 마킹되었을 시에만, 해당 사용자가 자신의 아이디와 자신의 새로운 공개키를 가지고, 본 문서에 기록된 대로, 최초 등록 시에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터의 저장 및 정상적으로 등록 진행, 그리고 최초 등록 이후에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터 및 인증정보를 가지고 등록, 인증, 탈퇴를 정상으로 진행한다. 이후, 최초 등록 시 및 최초 등록 이후의 두 경우 다, 포털서버에서 중계서버로부터 보조인증의 결과를 받고, 고객사 웹 서버가 로그인의 성공 유무를 포털서버로 물어보고, 해당 고객사 웹 서버가 사용자단말기로 성공 시 성공화면을 실패 시 실패 화면을 전송하는 마지막 끝까지 해당 사용자의 등록, 인증, 탈퇴를 사용자의 새로운 공개키로 정상적으로 진행 할 수 있다.

그리고, 중계서버에서 상기 성공신호와 중계서버에 미리 임시 저장된 인증정보와 중계서버에 미리 임시 저장된 등록데이터와의 비교를 실행 후에는, 중계서버에서 임시 저장된 해당 인증정보 및 중계서버에 임시 저장된 해당 등록데이터를 중계서버에서 삭제하는 단계(k)와; 상기 사용자단말기는 해당 고객사 웹 서버에게 자신이 최초 로그인 화면에서 받은 웹 쿠키 또는 웹 세션아이디 및 상기 포털서버로부터 받은 사용자 아이디와 성공 시에는 역시 상기 포털서버로부터 받은 time limit 이 있는 성공 토큰을, 실패 시에는 역시 상기 포털서버로부터 받은 상기 실패 메시지를 https로 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버에 문의한다. 이후, 고객사 웹 서버는 해당 사용자 아이디를 포털서버에 https로 문의하고, 해당 사용자 아이디에 해당되는 상기 성공 토큰이나 상기 실패 메시지를 사용자 아이디와 함께 고객사 웹 서버가 포털서버로부터 https를 활용해서 가져온다. 이후, 포털서버에서 포털서버에 임시 저장된 상기 time limit 이 있는 성공 토큰이나 사용자 아이디 및 실패 메시지나 사용자 아이디를 삭제한다. 이후, 사용자단말기가 고객사 웹 서버에게 https로 준 time limit 이 있는 성공 토큰과 고객사 웹 서버가 포털서버로부터 https로 가져온 time limit 이 있는 성공 토큰의 비교가 일치해서 성공 시에는 최종 성공을, 나머지의 경우에는 최종 실패를 결정하고 최종 성공 시 성공화면을 최종 실패 시 실패화면을 고객사 웹 서버가 사용자단말기로 https로 전송하는 단계(l); 을 포함함을 특징으로 한다.

상기 본 발명에 있어서, 상기 단계(f)에서, 상기 중계서버에서 사용자단말기가 중계서버로 보낸 인증정보의 경우, 사용자의 최초 등록 이후의 등록 및 인증, 탈퇴에서 중계서버에 미리 임시 저장된 등록데이터와 상기 중계서버가 받은 인증정보를 비교시 아이디별 공개키들이 불일치 시에는 사용자단말기로 실패 메시지를 전송한 후에 프로세스를 중단하며, 포털서버에서 중계서버로 보낸 성공신호와 사용자단말기가 중계서버에 보낸 인증정보 간의 shuffle 번호와 shuffle 번호 해쉬를 제외한 비교가 성공시까지만 상기 인증정보를 임시 저장한다. 이후, 성공신호와 상기 인증정보간의 비교가 실행 후에, 중계서버에 임시 저장된 등록데이터 및 중계서버에 임시 저장된 인증정보를 중계서버에서 삭제 처리하는 것을 포함함을 특징으로 한다.

상기 본 발명에 있어서, 상기 단계(i)에서, 해커가 중계서버를 사용하지 않고 포털서버와 직접적으로 등록, 인증, 탈퇴하려는 시도, 즉 해커의 중계서버 우회 등록, 우회 인증, 우회 탈퇴의 시도 시, 즉, 포털서버가 중계서버에게 보내고 shuffle 번호에 따라 복원된 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 성공신호에 해당되는 사용자단말기기가 중계서버로 보내고 shuffle 번호에 따라 복원된 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 중계서버에 미리 임시 저장된 인증정보가 중계서버에 없을 시, 해커의 중계서버를 우회해서 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버에서 포털서버로 상기 성공신호에 해당되는 난수정보가 포함된 실패 메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 포털서버에서 중계서버로부터 상기 실패 메지지와 사용자 아이디를 받으면, 사용자단말기에서 포털서버로 전송한 후에 shuffle 번호대로 복원되고 전자서명검증도 된, shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 전자서명값의 해쉬 값 등의 인증정보 중에서 고객사 웹 서버 URL이 해킹을 당했다고 보고 포털서버에서 사용자 아이디 내의 사용자 이메일 주소를 활용해서 해당 사고내용, 즉 해커가 중계서버를 우회해서 등록, 인증, 탈퇴를 하려는 중계서버 우회 등록, 우회 인증, 우회 탈퇴의 시도를 포털서버에서 이메일로 전송한다. 이후, 포털서버에서 해당 등록, 인증, 탈퇴를 최종적으로 취소하는 것을 포함함을 특징으로 한다.

상기 본 발명에 있어서, 상기 단계(j)에서, 개인키 유출사고 대응 시나리오는 중계서버를 사용해서 다른 사람의 사용자 아이디로 해당 사용자 아이디의 해킹된 개인키로 등록하거나 해당 개인키를 인증 및 탈퇴에서 사용하려는 해킹 시, 중계서버 내에서 최초 사용자 등록 시 미리 저장된 해당 사용자 아이디, 공개키, 이들의 사용자 서명 값인 등록데이터를 개인키 유출된 데이터로 마킹한다. 이후, 중계서버에서 shuffle 번호대로 복원된 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값의 성공신호를 중계서버에서 shuffle 번호대로 복원된 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값, 사용자 전자서명값의 해쉬 값 등의 중계서버에 미리 임시 저장된 인증정보와 중계서버에서 미리 임시 저장된 사용자 아이디, 공개키, 이들의 사용자 서명 값인 등록데이터와 비교한다. 즉, 개인키 유출로 마킹되고 최초 사용자 등록 시 미리 저장된 등록데이터의 사용자 아이디 및 공개키와 상기 성공신호, 상기 임시 저장된 인증정보, 및 상기 임시 저장된 등록데이터의 사용자 아이디와 공개키가 서로 일치 시 개인키 유출 사고로 보고, 중계서버에서 포털서버로 상기 성공신호내의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 하지만, 중계서버에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버에서 포털서버로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버가 중계서버로부터 실패 메시지와 사용자 아이디를 받았을 경우, 사용자단말기에서 포털서버로 전송한 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 인증정보 내에 있는 고객사 웹 서버 URL이 해킹을 당했다고 보고, 포털서버에서 사용자 아이디 내의 사용자 이메일 주소를 활용해서 사고 내용, 즉, 개인키 유출 사고 시 해커의 등록, 인증 시도를 이메일로 전송한다. 이후, 해커의 등록, 인증 시도를 포털서버에서 최종적으로 실패 처리한다. 이와는 달리, 포털서버가 중계서버로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받았을 경우에는, 포털서버가 받고 전자서명 검증된 인증정보 내에 있는 고객사 웹 서버 URL에서 개인키 유출 사고의 탈퇴 시도가 발생한 것으로 보고, 포털서버에서 사용자 아이디 내의 사용자 이메일 주소를 활용해서 사고 내용, 즉, 개인키 유출 사고 시 사용자 자신이나 해커의 탈퇴 시도를 이메일로 전송한다. 이후, 포털서버에서 사용자 자신 또는 해커의 해당 탈퇴를 최종적으로 진행한다. 또한, 상기 성공신호 전에 사용자단말기가 중계서버로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기가 중계서버에 보낸 인증정보의 아이디와 공개키가 사용자단말기가 중계서버로 보내고 중계서버에서 임시 저장된 상기 등록데이터와 일치하고 상기 임시 저장된 등록데이터가 사용자 최초 등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증의 경우, 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키들이 서로 일치하는 후자의 경우엔 중계서버에서 중계서버가 사용자단말기로부터 받은 인증정보 내의 고객사 웹 서버 URL이 개인키 유출 사고로 등록, 인증 해킹당했다는 사고 내용을 인증정보 내의 사용자 아이디 내의 사용자 이메일주소를 활용해서 이메일로 전송한 후에 해당 등록, 인증 프로세스를 중단한다. 이와는 달리 개인키 유출 사고의 탈퇴의 경우, 중계서버에서 아무런 이메일 대응이 없이, 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴로 보고 해당 프로세스를 그대로 진행하는 것을 포함함을 특징으로 한다.

상기 본 발명에 있어서, 상기 단계(j)에서, 다른 사용자의 다른 공개키 등록, 인증, 탈퇴 해킹 탐지는 중계서버를 사용해서 다른 사람의 사용자 아이디로 다른 공개키를 등록, 인증 및 탈퇴에서 사용하려는 해킹 시, 포털서버가 중계서버에게 보내고 shuffle 번호에 따라 복원된 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값의 성공신호를 사용자단말기기가 중계서버로 보내고 shuffle 번호에 따라 복원된 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 중계서버에 미리 임시 저장된 인증정보와 비교해서 성공신호의 공개키 등의 데이터가 상기 임시 저장된 인증정보의 해당 공개키 등과 사용자 아이디를 기준으로 불일치 시, 중계서버에서 포털서버로 상시 성공신호에 해당되는 난수정보가 포함된 실패 메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 포털서버에서 중계서버로부터 상기 실패 메시지와 사용자 아이디를 받으면, 사용자단말기에서 포털서버로 전송한 후에 shuffle 번호대로 복원되고 전자서명검증도 된, shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 인증정보 중에서 고객사 웹 서버 URL이 해킹을 당했다고 보고 포털서버에서 사용자 아이디 내의 사용자 이메일 주소를 활용해서 해당 사고내용, 즉 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴 하려는 해킹 시도를 포털서버에서 이메일로 전송한다. 이후, 포털서버에서 해당 등록, 인증, 탈퇴를 최종적으로 취소한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키들이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키가 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단하고, 개인키 유출로 중계서버에서 해당 사용자의 등록데이터 안의 공개키가 마킹되었을 시에만, 해당 사용자가 자신의 아이디와 자신의 새로운 공개키를 가지고, 본 문서에 기록된 대로, 최초 등록 시에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터의 저장 및 정상적으로 등록 진행, 그리고 최초 등록 이후에는 중계서버에서 사용자 자신의 새로운 공개키가 포함된 등록데이터 및 인증정보를 가지고 등록, 인증, 탈퇴를 정상으로 진행한다. 이후, 최초 등록 시 및 최초 등록 이후의 두 경우 다, 포털서버에서 중계서버로부터 보조인증의 결과를 받고, 고객사 웹 서버가 로그인의 성공 유무를 포털서버로 물어보고, 해당 고객사 웹 서버가 사용자단말기로 성공 시 성공화면을 실패 시 실패 화면을 전송하는 마지막 끝까지 해당 사용자의 등록, 인증, 탈퇴를 사용자의 새로운 공개키로 정상적으로 진행 할 수 있는 것을 포함함을 특징으로 한다.

상술한 바와 같이, 본 발명인 포털사이트 중계 서비스 제공 시스템 및 그 방법은 다음과 같은 효과를 가진다.

첫째, 본 발명은 SSO(Single Sign On)와 같이 단일계정으로 편리하고 FIDO와 같이 보안 수준이 높은 방법을 이용하여 고객사의 웹 서버가 사용자의 등록, 인증, 탈퇴의 서비스를 제공할 수 있다.

둘째, 본 발명은 사용자단말기는 고객사의 웹 서버마다 별도로 아이디, 패스워드를 기억하고 있을 필요 없이 단일한 사용자 아이디와 비대칭키 한 쌍만을 가지고도 모든 고객사 웹 서버들로 직접 접속하는 것과 같은 편리함과 고객사 웹 서버 입장에서는 FIDO 와 같은 원리로 안전하고 간편한 인증 수단을 누리게 해 주는 포털사이트 중계 서비스를 제공할 수 있다.

셋째, 본 발명은 FIDO와 달리 중계서버를 사용해서 단일계정이 가능하고 사용자단말기가 중계서버로 주는 등록데이터 및 인증정보와 포털서버가 중계서버로 주는 성공신호 및 사용자의 최초 등록 시 중계서버에 저장된 등록데이터를 사용해서 개인키 유출사고 대응 및 이메일 대응, 중계서버의 우회 등록, 우회 인증, 우회 탈퇴의 해킹 대응 및 이메일 대응, 그리고 다른 사용자의 아이디로 다른 공개키를 임의의 포털사이트에서 등록, 인증, 탈퇴하려는 것을 방지할 수 있는 해킹 대응 및 이메일 대응이 추가로 가능하게 되어 FIDO 보다 보안이 높다.

넷째, 본 발명은 각 사용자단말기는 별도의 패스워드를 관리하지 않고도, 포털서버가 중계서버를 통해 사용자단말기로 사용자 난수를 보내고, 이후, 사용자단말기가 난수 원문과 비대칭키로 전자서명화한 사용자 난수암호화를 포털서버로 보내며, 포털서버가 이 사용자 난수암호화를 사용자 공개키를 활용해서 전자서명을 검증 후에 자신이 보낸 사용자 난수와 서로 일치하는지 검증함으로써, 사용자 입장에서는 자신의 개인키가 노출되지 않는다면 개인의 인증이 확실히 보장되고, 포털사이트 입장에서는 매번 달라지는 난수 때문에 해커의 replay 공격을 방어할 수 있어 때문에 보안성이 향상될 수 있다.

다섯째, 본 발명은 중계서버가 구성 요소에 첨가됨으로써, 사용자단말기는 단일계정으로 모든 포털사이트에 가입할 수 있음은 물론 포털사이트가 중계서버로 성공신호를 보내서 보조 인증을 한 번 더 물을 수 있으므로 개인키 유출 시 사고 대응 및 해당 사용자에게 사고내용을 전달하는 이메일 대응이나, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하는 해킹 대응 및 해당 사용자에게 사고내용을 전달하는 이메일 대응, 그리고 중계서버 우회 등록, 우회 인증, 우회 탈퇴의 해킹을 방지하고 해당 사용자에게 이메일로 사고내용을 전달할 수 있다. 또한, 상기 성공신호 전에 사용자단말기가 중계서버로 등록데이터 및 인증정보를 보내고 이들을 중계서버에 사용자 최초 등록 시에 미리 저장된 등록데이터와 비교해서, 개인키 유출 사고의 등록, 인증 및 해커가 다른 사용자 아이디의 다른 공개키를 사용해서 등록, 인증, 탈퇴하려는 해킹 시도를 탐지하고 등록데이터 끼리의 비교 시에는 프로세스를 중단하고, 등록데이터와 인증정보의 비교시에는 이메일 대응 후에, 해당 프로세스를 중단하는 기능도 가능하다.

여섯째, SSO(Single Sign On) 의 경우, 중앙서버에서 모든 사용자들의 텍스트 암호관리를 해야 하고 FIDO(Fast Indentity Online) 의 경우 중앙서버에서 모든 사용자들의 공개키 관리를 해야 하는데, 이때 사용자 수가 대한민국의 사람 수인 5000만명만 되어도 텍스트 암호관리를 하는 중앙서버나 공개키 관리를 해야 하는 중앙서버의 DB 의 한계가 발생하게 된다. 반면에, 본 기술은 FIDO처럼 사용자가 각자 개인키를 관리하기 때문에 보안성이 기존 텍스트 암호화보다 높지만, 중계서버들마다 사용자들을 의도대로 분산 배치시킬 수 있는 상황에서 사용자들을 고객사의 포털서버들 및 고객사 웹 서버들로 연결시킬 수 있기 때문에, 즉, 중계서버 1개에 사용자 수를 임의로 지정할 수 있어, 단일계정을 보장하면서도 사용자 수에 제한이 없게 된다. 즉, 사용자 수가 늘어나면 중계서버를 늘리면 되기 때문에 단일계정을 가정 시 SSO 나 FIDO 처럼 중앙서버의 DB의 한계가 없어지게 된다. 즉, 중계서버 1개에 사용자 수를 임의로 지정할 수 있게 되서 사용자 수가 아무리 늘어나도 중계서버를 늘리면 되기 때문에 중계서버의 DB 의 한계가 발생하지 않는다. 또한, 본 기술은 단일계정을 가정해도 사용자가 늘어나면 초당 인증건수인 throughput 이 느려지는 SSO 나 FIDO 와는 달리 사용자 수가 아무리 늘어나도 초당 인증건수인 throughput 이 전혀 늘어나지 않는다. 다시 말해, 중계서버들을 사용하고 사용자가 전용 중계서버를 사용하는 본 기술의 특징 상, 사용자 수가 아무리 늘어나도 중계서버를 늘리면 되기 때문에, 기존의 SSO 나 FIDO 기술처럼 특정 중앙서버의 DB 한계 때문에 발생하는 throughput이 느려지는 현상이 발생하지 않는다. 따라서, 본 기술은 사용자 수가 아무리 많아져도 throughput 이 늘어나는 문제점이 전혀 발생하지 않고 throughput 이 유지된다.

일곱 번째, 블록체인 DID 와 비교해도, 블록체인 내의 각각의 노드들이 사용자들의 공개키를 다 담아야 하기 때문에, 블록체인은 상기 SSO 나 FIDO처럼 중앙서버의 DB 의 한계 때문에 사용자 수에 제한이 있을 수밖에 없으며, 사용자 수가 늘어날 수록 초당 인증건수인 throughput 이 느려질 수밖에 없다. 반면에, 본 기술은 지구상의 전 인류의 수인 70억명의 사용자가 본 기술을 사용해서 단일계정으로 묶여도, 사용자 수의 한계나 중앙서버 DB 의 한계, 또는 초당 인증 건수인 throughput 의 한계가 본 기술에선 중계서버들에서 사용자들을 분산관리 할 수 있기 때문에 본 기술에선 발생하지 않는다. 무엇보다 본 기술은 사용자단말기가 등록, 인증, 탈퇴 시 마다, 사용자의 공개키를 포털서버로 보내고 포털서버에서 사용자 전자서명 검증을 매번 하고 공개키를 따로 포털서버에서 DB 에 저장하지 않기 때문에, 사용자단말기가 가지고 있는 개인키와 공개키만 해킹당하지 않으면 중앙서버에서 공개키를 관리하는 데서 오는 중앙서버의 공개키 위변조 해킹 취약점이 발생하지 않는다. 즉, 본 기술은 사용자단말기기가 등록, 인증, 탈퇴 시마다 매번 공개키를 포털서버로 보내주고 포털서버에서 매번 전자서명검증을 하고 포털서버에서 공개키를 DB 에 저장하지 않아도 되는 구조이기 때문에, 중앙서버의 위변조 취약점이 전혀 발생하지 않고, 위변조의 취약점이 개개인의 사용자단말기로 분산되는 효과를 가져온다. 따라서, 즉, 공개키의 신뢰성을 보장하는 대신 사용자의 개인키가 해킹당하면 보안 취약점이 발생하는 블록체인 DID 기술과 본 기술의 보안 수준을 서로 비교 시, 본 기술도 사용자단말기가 방어되면 중앙서버의 공개키 위변조 현상이 방어가 되기 때문에 해커가 공격하는 대상이 블록체인 DID 와 같이 사용자단말기로 귀결된다는 점에서 본 기술은 블록체인 DID 와 보안수준이 비슷할 것이다. 여기서, 가정은 사용자단말기의 개인키가 해킹당했다는 얘기는 사용자단말기의 DB가 해킹당했다고 보는 것이고, 이는 DB 의 계정이 해킹당했다는 것이기 때문에 공개키도 같이 해킹당할 수밖에 없다는 것이다. 즉, 개인키 해킹과 개인키 및 공개키 동시 해킹은 서로 별개가 아니라 보안 측면에선 보안 수준이 동일 시 될 수 있다는 점이다.

도 1은 본 발명의 일실시예에 따른 포털사이트 중계 서비스 제공 시스템에서 등록과정과, 인증 및 탈퇴과정을 설명하기 위해 나타낸 도면.
도 2는 본 발명의 일실시예에 따른 포털사이트 중계 서비스 제공 시스템에서 사용자 아이디 아키텍쳐를 설명하기 위해 나타낸 도면.
도 3은 본 발명의 일실시예에 따른 포털사이트 중계 서비스 제공 시스템에서 개인키의 유출사고 대응 시나리오 및 해커의 중계서버를 우회해서 등록, 인증, 탈퇴하려는 시도인 해커의 우회 등록, 우회 인증, 우회 탈퇴 시도 대응 시나리오를 설명하기 위해 나타낸 도면.
도 4는 본 발명의 일실시예에 따른 포털사이트 중계 서비스 제공 시스템에서 다른 사용자의 다른 공개키의 등록, 인증, 탈퇴를 해킹하는 것을 탐지하는 시나리오 및 해커의 중계서버를 우회해서 등록, 인증, 탈퇴하려는 시도인 해커의 우회 등록, 우회 인증, 우회 탈퇴 시도 대응 시나리오를 설명하기 위해 나타낸 도면.

이하 첨부된 도면과 함께 본 발명의 바람직한 실시예를 살펴보면 다음과 같은데, 본 발명을 설명함에 있어서 관련된 공지기술 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략할 것이며, 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있으므로, 그 정의는 본 발명인 포털사이트 중계 서비스 제공 시스템 및 그 방법을 설명하는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 일실시예에 따른 포털사이트 중계 서비스 제공 시스템을 상세하게 설명한다.

도 1은 본 발명의 일실시 예에 따른 포털사이트 중계 서비스 제공 시스템에서 등록과정과, 인증 및 탈퇴과정을 설명하기 위해 나타낸 도면이고, 도 2는 본 발명의 일실시예에 따른 포털사이트 중계 서비스 제공 시스템에서 사용자 아이디 아키텍쳐를 설명하기 위해 나타낸 도면이며, 도 3은 본 발명의 일실시예에 따른 포털사이트 중계 서비스 제공 시스템에서 개인키의 유출사고 대응 시나리오 및 해커의 중계서버를 우회해서 등록, 인증, 탈퇴하려는 시도인 해커의 우회 등록, 우회 인증, 우회 탈퇴 시도 대응 시나리오를 설명하기 위해 나타낸 도면이고, 도 4는 본 발명의 일실시예에 따른 포털사이트 중계 서비스 제공 시스템에서 다른 사용자의 다른 공개키의 등록, 인증, 탈퇴를 해킹하는 것을 탐지하는 시나리오 및 해커의 중계서버를 우회해서 등록, 인증, 탈퇴하려는 시도인 해커의 우회 등록, 우회 인증, 우회 탈퇴 시도 대응 시나리오를 설명하기 위해 나타낸 도면이다.

상기 본 발명인 포털사이트 중계 서비스 제공 시스템은 고객사 웹 서버(100), 사용자단말기(또는 사용자단말기 클라이언트)(200), 포털서버(SIDSL 서비스 서버)(300), 중계서버(relay server)(400) 등으로 구성된다.

도 1 내지 도 4에 도시한 바와 같이, 본 발명인 포털사이트 중계 서비스 제공 시스템은 고객사 웹 서버(100)에서 사용자단말기(200)로 고객사의 로그인 화면이 https로 디스플레이 되게 하는 기능과, 상기 고객사 웹 서버(100)는 사용자단말기(200)가 해당 고객사 웹 서버(100)에게 사용자 아이디와 자신이 최초 로그인 화면에서 받은 웹 쿠키 또는 웹 세션아이디 및 성공 시에는 time limit 이 있는 성공 토큰을, 실패 시에는 실패메시지를 https로 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버(100)에 https로 문의한다. 이후, 고객사 웹 서버(100)는 해당 사용자 아이디를 포털서버에게 https로 문의하고 고객사 웹 서버는 포털서버로부터 해당 사용자 아이디에 해당되는 time limit이 있는 성공 토큰이나 실패메시지를 사용자 아이디와 함께 가져온다. 이후, 포털서버에서 포털서버에 임시 저장된 상기 time limit 이 있는 성공 토큰이나 사용자 아이디 및 실패메시지나 사용자 아이디를 삭제한다. 이후, 사용자단말기(200)가 고객사 웹 서버(100)에게 준 성공 토큰과 고객사 웹 서버(100)가 포털서버(300)로부터 가져온 성공 토큰의 비교가 일치해서 성공 시에는 최종 성공을, 나머지의 경우에는 최종 실패를 결정하고 최종 성공 시 성공화면을 최종 실패 시 실패화면을 고객사 웹 서버가 사용자단말기로 https를 활용해서 전송한다. 이후, 고객사 웹 서버(100)에서 등록 성공 시, 고객사 웹 서버에서 고객사 웹 서버(100) 전용 아이디와 본 기술의 사용자 아이디를 매칭시켜 고객사 웹 서버 DB에 이 매칭된 정보들을 저장하는 기능을 갖는 것을 특징으로 하는 고객사 웹 서버(100)와; 상기 고객사 웹 서버(100)로부터 고객사의 로그인 화면을 https로 디스플레이 받는 기능과, 사용자단말기(200)에서 중계서버(relay server)(400)로 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 서명 값을 https로 전송하고, 이후,

사용자의 최초 등록 시에는, 상기 등록데이터의 사용자 아이디(즉, 사용자의 이메일주소+지역번호) 내의 지역번호가 해당 중계서버(400)와 맞지 않으면 프로세스를 중단하고, 이후, 중계서버(400)에서 등록데이터 내의 사용자 아이디의 유일성을 검증 후, 실패 시 프로세스를 중단하고, 이후, 중계서버(400)에서 상기 등록데이터를 전자서명 검증한 후 저장하며, 실패 시 해당 등록데이터를 저장하지 않고 프로세스를 중단한다. 그리고, 사용자의 최초 등록 이후의 등록 및 인증, 탈퇴 시 에는 중계서버(400)에 저장된 등록데이터와 사용자단말기가 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭이 되더라도 서로를 해쉬 값으로 서로 비교한 후 불일치 시 프로세스를 중단하고, 이후에, 최초 사용자 등록 및 최초 사용자 등록 이후의 등록, 인증, 탈퇴 시에는 상기 사용자단말기(200)로부터 받은 등록데이터를 중계서버(400)에 임시 저장하는 기능과, 상기 중계서버(400)로부터 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송받는 기능과, 사용자단말기(200)에서 중계서버(400)로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 데이터를 shuffle 번호대로 shuffle해서 https로 전송한 후, 중계서버(400)에서 shuffle 번호대로 복원한다. 복원 시, 인증정보내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때, 원본들을 해쉬한 것들과 원본의 해쉬들이 서로 일치하지 않는 것이 하나라도 있으면 프로세스를 중단한다. 이후, 중계서버(400)에서 필요한 경우 추가적으로 해당 인증정보의 전자서명을 검증받고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 않아도 된다. 이후, 해당 인증정보와 중계서버에 미리 임시 저장된 해당 등록데이터의 사용자 아이디와 공개키 등을 서로 비교해서 불일치 시 프로세스를 중단한다. 이후에, 해당 인증정보를 중계서버(400)에 임시 저장하는 기능과, 사용자단말기(200)에서 포털서버(SIDSL 서비스 서버)(300)로 상기 인증정보를 shuffle 번호대로 shuffle 한 후에 https로 전송하는 기능과, 포털서버(300)에서 인증정보를 shuffle 번호대로 복원에 성공한 후, 즉, 복원된 인증정보 내에서의 원본들과 원본의 해쉬들에서 원본들을 해쉬한 것들과 원본의 해쉬들을 서로 비교시 하나라도 불일치하는 것이 없는 것을 확인한다.

이 경우 만약 포털서버(300)가 복원 성공 검증된 인증정보 내의 사용자 공개키를 이용하여 그 인증정보에 대한 전자서명 검증을 수행하도록 한다면 다음과 같은 문제점이 발생할 수 있다. 즉, 인증정보의 공개키가 해커의 공개키인 경우, 해커가 자신의 개인키로 전자서명을 하기 때문에 해당 인증정보에 대한 전자서명 검증은 당연히 통과되게 되어, 해커에 의하여 다음 과정이 계속 수행되게 되는 문제점이 있게 된다.

이러한 문제점을 해결하기 위하여 포털서버(300)는, 복원 성공 검증된 인증정보 내의 사용자 아이디와 사용자 공개키를 활용해서, 즉 더욱 구체적으로는 사용자 아이디 내의 지역번호와 사용자 공개키 안의 중계서버 URL 정보를 활용해서, 해당 중계서버(400)로 해당 사용자 아이디의 공개키를 문의한다. 이 경우, 포털서버(300)가 인증정보 내의 사용자 아이디를 중계서버(400)로 보내면, 중계서버(400)에서 그 사용자 아이디에 해당되는 등록데이터를 찾아서, 그 등록데이터 안의 해당 공개키를 찾은 후 이를 다시 포털서버(300)로 보낸다. 이에 따라 포털서버(300)가 중계서버(400)로부터 수신한 공개키로써 인증정보를 전자서명 검증하게 되는 것이다. 즉, 포털서버(300)가 사용자단말기(200)로부터 수신하여 복원 성공 검증한 인증정보 내의 사용자 공개키가 해킹된 공개키라 하더라도, 포털서버(300)는 그 공개키를 사용하지 않고, 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증하기 때문에, 해킹된 경우에는 전자서명 검증을 통과할 수 없게 하는 것이다.

이후, 이와 같이 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증을 수행한 후에, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버(400)를 통해 사용자단말기기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버(300)에서 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후에, 이 실패메시지와 사용자 아이디를 포털서버에서 사용자단말기로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 중계서버(400)를 통해 사용자단말기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값 중에서 사용자 아이디와 난수와 서로 일치하는 지 확인한 후, 성공 시 포털서버(300)에서 등록, 인증, 탈퇴 성공을 한 후에 상기 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이후, 상기 성공신호를 포털서버(300)에서 중계서버(400)로 VPN 이나 https를 활용해서 shuffle 번호에 따라 shuffle 해서 보낸 후 중계서버(400)에서 보조 인증을 한 후에 성공 시, 즉, 해커나 사용자 자신의 개인키 유출 사고의 탈퇴나 나머지 보조인증의 성공 시, 포털서버(300)에서 time limit 이 있는 성공 토큰을 생성한 후에 이를 사용자 아이디와 함께 포털서버에 임시 저장한 후에, 이 time limit이 있는 성공 토큰과 사용자 아이디를 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리, 중계서버(400)에서 보조 인증을 한 후에 실패 시, 즉, 개인키 유출 사고의 등록, 인증의 경우, 해커의 다른 사용자 아이디를 활용한 다른 공개키의 등록, 인증, 탈퇴의 경우, 또는 해커의 중계서버를 우회해서 등록, 인증, 탈퇴하려는 우회 등록, 우회 인증, 우회 탈퇴의 경우, 포털서버(300)에서 사용자 아이디와 중계서버(400)로부터 받은 실패메시지를 임시로 저장한 후에 이 사용자 아이디와 실패메시지를 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 전송하는 기능과, 상기 사용자단말기(200)에서 고객사 웹 서버(100)로 사용자 아이디, 웹 쿠키 및 웹 세션아이디, 그리고 성공 시에는 time limit 이 있는 성공 토큰을, 실패 시에는 상기 실패메시지를 https로 전송한 후에 고객사 웹 서버(100)로부터 사용자단말기가 성공 시 성공 화면을 실패 시 실패 화면을 https로 전송받는 기능을 갖는 사용자단말기(200)와; 중계서버(400)로부터 등록 데이터를 https로 전송받고 포털서버(300)에서 사용자 아이디, 난수, 이들의 해쉬값을 중계서버(400)로 https를 활용해서 전송하는 기능과, 사용자단말기(200)가 포털서버(300)로 인증정보를 shuffle 번호대로 shuffle 해서 https로 보내고 포털서버(300)에서 해당 데이터를 shuffle 번호대로 원복해서 인증정보를 받는다. 이때, 포털서버(300)에서 shuffle 번호에 따라 복원 시, 인증정보내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 일치하지 않는 것이 하나라도 있으면 프로세스를 중단한다.

인증정보가 복원 성공 검증된 경우, 만약 포털서버(300)가 복원 성공 검증된 인증정보 내의 사용자 공개키를 이용하여 그 인증정보에 대한 전자서명 검증을 수행하도록 한다면 다음과 같은 문제점이 발생할 수 있다. 즉, 인증정보의 공개키가 해커의 공개키인 경우, 해커가 자신의 개인키로 전자서명을 하기 때문에 해당 인증정보에 대한 전자서명 검증은 당연히 통과되게 되어, 해커에 의하여 다음 과정이 계속 수행되게 되는 문제점이 있게 된다.

이후, 이와 같이 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증을 수행한 후에, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버(400)를 통해 사용자단말기기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버에서 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후에, 이들을 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 중계서버(400)를 통해 사용자단말기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값 등의 데이터 중의 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 포털서버(300)에서 해당 등록, 인증, 탈퇴를 임시 성공 처리 한다. 이후, 상기 포털서버(300)가 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버(300)에서 중계서버(400)로 shuffle 번호대로 shuffle 한 후에 VPN 이나 https를 활용해서 전송하고, 중계서버(400)에서 shuffle 번호대로 복원한다. 복원 시, 성공신호 내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 일치하지 않는 것이 하나라도 있으면 프로세스를 중단한다. 이후, 포털서버(300)가 중계서버(400)로 VPN 이나 https를 활용해서 보낸 성공신호와 사용자단말기(200)가 중계서버(400)로 https를 활용해서 보내고 중계서버에 임시 저장된 인증정보를 중계서버(400)에서 서로 비교해서, shuffle 번호와 shuffle 번호 해쉬를 제외하고 모두가 다 서로 일치하고 해당 성공신호에 해당되는 중계서버(400)에서 사용자 최초 등록 시에 미리 저장된 등록데이터가 개인키 유출로 마킹된 것이 아니라면, 중계서버(400)에서 상기 성공신호와 인증정보를 비교하는 보조인증을 성공으로 설정하고 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호의 난수정보가 포함된 성공 메시지와 사용자 아이디를 보낸다. 또한, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에도 보조인증을 성공으로 설정하고 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이와 달리, 중계서버(400)에서 사용자단말기(200)가 중계서버(400)로 보내고 중계서버에 임시 저장된 등록데이터가 사용자 최초 등록 시에 중계서버에 미리 저장되어 있고 개인키 유출로 마킹이 되어 있는 등록데이터와 일치하고, 상기 성공신호와 중계서버(400)에 미리 임시 저장된 인증정보 및 중계서버(400)에 미리 임시 저장된 등록데이터의 사용자 아이디와 공개키 등이 서로 일치하면 해커가 유출된 개인키로 해킹하는 것으로 보고 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호의 난수정보가 포함된 실패메시지와 사용자 아이디를 보낸다. 하지만, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 또한, 중계서버(400)에서 성공신호와 중계서버(400)에 미리 임시 저장된 인증정보를 사용자 아이디를 기준으로 비교해서 공개키 등이 서로 불일치할 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도로 보고 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호의 난수정보가 포함된 실패메시지와 사용자 아이디를 보낸다. 또한, 중계서버(400)에서 성공신호가 있으나 해당 인증정보가 없다면 중계서버를 우회 등록, 우회 인증, 우회 탈퇴하려는 해킹 시도로 보고 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 보낸다. 이후, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 포털서버(300)에서 사용자단말기(200)로부터 받은 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버(100) URL에서 개인키 유출 사고로 마킹된 공개키로 해커가 등록, 인증을 하려고 했거나, 또는 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도, 또는 해커가 중계서버(400)를 우회 등록, 우회 인증, 또는 우회 탈퇴 하려는 시도로 보고 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고한다. 그리고, 상기에서 포털서버(300)에서 중계서버(400)로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받은 경우, 포털서버(300)에서 사용자단말기(200)로부터 받은 전자서명 검증된 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 탈퇴를 할려고 하는 시도로 보고 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고한다. 이후, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 개인키 유출 사고의 등록, 인증의 경우 포털서버에서 최종적으로 등록, 인증 취소를 하고, 이와는 달리, 중계서버(400)로부터 성공메시지와 사용자 아이디를 받은 개인키 유출 사고의 탈퇴의 경우, 즉, 사용자 자신이나 해커의 탈퇴의 경우 포털서버(300)에서 해당 탈퇴를 최종적으로 진행한다. 이와는 달리, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 다른 공개키 등록, 인증, 탈퇴의 경우엔, 포털서버(300)에서 최종적으로 등록, 인증, 탈퇴 취소를, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 중계서버 우회 해킹의 등록, 인증, 탈퇴의 경우엔, 포털서버(300)에서 최종적으로 우회 등록, 우회 인증, 우회 탈퇴를 취소한다. 이후, 포털서버(300)가 중계서버(400)로부터 성공 메시지와 사용자 아이디를 받은 나머지의 경우, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 성공처리한다. 이후, 포털서버(300)에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버(300)에 임시 저장하고, 이 time limit 이 있는 성공 토큰과 사용자 아이디를 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 보낸다. 반대로, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 포털서버(300)에서 해당 사용자 아이디 및 상기 실패메시지를 임시 저장하고, 이들을 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 보내는 기능을 갖는 포털서버(SIDSL 서비스 서버)(300)와; 상기 사용자단말기(200)로부터 중계서버(relay server)(400)로 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 https로 전송받고, 이후, 사용자의 최초 등록 시에는, 해당 등록데이터의 사용자 아이디(즉, 사용자의 이메일 주소+지역번호) 내의 지역번호가 중계서버와 맞지 않으면 프로세스를 중단한다. 이후, 중계서버(400)에서 등록데이터 내의 사용자 아이디의 유일성을 검증 후, 실패 시 프로세스를 중단하고, 이후, 중계서버(400)에서 등록데이터의 전자서명을 검증한 후 저장하며, 실패 시 해당 등록데이터를 저장하지 않고 프로세스를 중단한다. 그리고, 사용자의 최초 등록 이후의 등록 및 인증, 탈퇴 시에는 중계서버에 사용자 최초 등록 시 미리 저장된 등록데이터와 사용자단말기(200)가 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭이 되더라도 서로를 해쉬 값으로 비교한 후 불일치 시 프로세스를 중단하고, 이후, 사용자 최초 등록 및 사용자 최초 등록 이후의 등록, 인증, 탈퇴의 경우 상기 사용자단말기(200)로부터 받은 등록데이터를 중계서버(400)에 임시 저장한다. 이후, 포털서버(300)로 해당 등록 데이터를 https로 전송하고 포털서버(300)로부터의 사용자 아이디, 난수, 이들의 해쉬 값을 중계서버(400)로 https로 전송받는 기능과, 상기 사용자단말기(200)로 상기 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송하는 기능과, 사용자단말기(200)에서 중계서버(400)로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 데이터를 shuffle 번호대로 shuffle 해서 https로 전송한 후, shuffle 번호대로 중계서버에서 복원한다. 복원 시, 인증정보내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 일치하지 않는 것이 하나라도 있으면 프로세스를 중단한다. 이후, 중계서버(400)에서 필요한 경우 추가적으로 해당 인증정보의 전자서명을 검증하고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 않아도 되는 기능과, 이 인증정보와 해당 중계서버(400)에 미리 임시 저장된 등록데이터와 비교시 사용자 아이디별 공개키들이 서로 불일치 시 프로세스를 중단한다. 이후에, 해당 인증정보를 중계서버(400)에 임시 저장하는 기능과, 사용자단말기(200)가 포털서버(300)로 상기 인증정보를 shuffle 번호대로 shuffle 한 후에 https를 활용해서 보내고 포털서버(300)에서 shuffle 번호대로 원복을 실시한다.

이후, 이와 같이 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증을 수행한 후에, 이 전자서명 검증이 실패하거나 상기 전자서명 검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버(400)를 통해 사용자단말기기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버(300)에서 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후에, 이 실패메시지와 사용자 아이디를 포털서버에서 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버(300) 자신이 중계서버(400)를 통해 사용자단말기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값 등의 데이터 중의 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 상기 포털서버(300)에서 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버(300)에서 중계서버(400)로 shuffle 번호대로 shuffle 한 후 VPN 이나 https를 활용해서 전송하고, 중계서버(400)에서 shuffle 번호대로 복원한다. 복원 시, 성공신호내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 일치하지 않는 것이 하나라도 있으면 프로세스를 중단한다. 이후, 상기 성공신호에 해당되는 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 중계서버(400)에 미리 임시 저장된 인증정보가 중계서버(400)에 없을 경우 중계서버(400)에서 포털서버(300)로 상기 성공신호내의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 포털서버가 중계서버로부터 상기 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 받으면, 사용자단말기(200)가 포털서버(300)로 보내고 전자서명 검증된 인증정보의 포털서버 URL이 우회 등록, 우회 인증, 또는 우회 탈퇴 해킹당했다고 보고 포털서버(300)에서 사용자 아이디 내의 사용자 이메일을 활용해서 해당 사용자에게 해당 사고 내용을 이메일로 전송한다. 이후, 포털서버(300)에서 해당 우회 등록, 우회 인증, 우회 탈퇴를 최종적으로 취소하는 기능과, 이와는 달리, 중계서버(400)에서 성공신호에 해당되는 임시 저장된 인증정보가 있지만, 사용자 아이디별 공개키 등이 서로 불일치하는 경우, 중계서버(400)를 이용해서 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹시도로 보고, 또한 중계서버(400)에서 성공신호에 해당되는 임시 저장된 인증정보 및 임시 저장된 등록데이터가 있지만, 성공신호가 상기 인증정보 및 상기 등록데이터와 사용자 아이디 및 공개키 등이 서로 일치하지만, 상기 임시 저장된 등록데이터가 개인키 유출로 신고되서 마킹되어 있고 최초 사용자 등록 시 중계서버(400)에 미리 저장된 등록데이터와 서로 일치 시, 중계서버(400)를 이용한 개인키 유출 사고로 본다. 이 두 경우 다 중계서버(400)에서 포털사이트로 상기 성공신호내의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 하지만, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)가 중계서버(400)로부터 상기 실패메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)가 포털서버(300)로 보내고 전자서명 검증된 해당 인증정보의 고객사 웹 서버(100) URL이 해킹된 것으로 보고, 즉, 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려고 하거나 개인키 유출 사고의 경우 해커가 유출된 개인키로 등록, 인증을 하려는 시도로 보고 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 각각의 사고 내용에 대한 이메일 전송을 포털서버(300)에서 한다. 그리고, 포털서버(300)가 중계서버(400)로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받았을 경우, 사용자 자신이나 해커의 탈퇴 시도로 보고 사용자 아이디 내의 이메일 주소를 활용해서 각각 이메일 전송을 포털서버(300)에서 한다. 이후, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 즉, 포털사이트에서 다른 공개키 등록, 인증, 탈퇴의 경우엔, 최종적으로 등록, 인증, 탈퇴 취소를 하고, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 개인키 유출 사고의 경우 최종적으로 등록, 인증 취소를 하고, 포털서버(300)에서 중계서버(400)로부터 성공 메시지와 사용자 아이디를 받은 개인키 유출 사고의 탈퇴에서 사용자 자신 또는 해커의 탈퇴의 경우 포털서버(300)에서 해당 탈퇴를 최종적으로 진행한다. 이와는 달리, 상기 포털서버(300)가 중계서버(400)로 shuffle 번호대로 shuffle해서 VPN 이나 https로 보내고 중계서버(400)에서 shuffle 번호대로 복원에 성공한 성공신호와 해당 성공신호에 해당되는 사용자단말기(200)가 중계서버(400)로 shuffle 번호대로 shuffle 해서 https로 보내고 중계서버(400)에서 shuffle 번호대로 복원에 성공한 후에 중계서버(400)에 미리 임시 저장된 인증정보가 있고, 상기 성공신호와 상기 인증정보가 서로 shuffle 번호와 shuffle 번호 해쉬를 제외하고 일치할 경우, 그리고, 상기 성공신호에 해당되는 중계서버(400)에서 사용자의 최초 등록 시 미리 저장된 등록데이터가 개인키 유출로 마킹된 경우가 아니라면, 보조인증을 성공으로 보고, 포털서버가 받은 상기 성공신호 내의 난수가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)에서 성공 메시지와 사용자 아이디를 받으면 최종적으로 등록, 인증, 탈퇴를 성공으로 처리한다. 하지만, 상기 성공신호 전에 사용자단말기(200)에서 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기(200)에서 중계서버(400)로 보낸 인증정보의 사용자 아이디와 공개키가 상기 미리 임시 저장된 등록데이터와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키들이 서로 일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보 내의 해당 고객사 웹 서버(100) URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 등록 또는 인증을 하려고 하는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만, 개인키 유출 사고의 탈퇴의 경우 해당 중계서버에서 해당 프로세스를 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키들이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키들이 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단하는 기능을 갖는 중계서버(400); 을 구비한다.

상기 본 발명인 포털사이트 중계 서비스 제공 시스템을 구성하는 각 기술적 수단들의 기능을 설명하면 다음과 같다.

상기 고객사 웹 서버(100)는 고객사 웹 서버(100)에서 사용자단말기(200)로 고객사의 로그인 화면이 https로 디스플레이 되게 하는 기능과, 해당 사용자단말기(200)는 해당 고객사 웹 서버(100)에게 사용자 아이디와 자신이 최초 로그인 화면에서 받은 웹 쿠키나 웹 세션아이디 및 성공 시에는 time limit 이 있는 성공 토큰을, 실패 시에는 실패메시지를 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버(100)에 https로 문의한다. 이후, 고객사 웹 서버(100)는 해당 사용자 아이디를 포털서버(300)에게 https로 문의하고 등록, 인증, 탈퇴에 대해서 time limit 이 있는 성공 토큰이나 실패메시지를 사용자 아이디와 함께 고객사 웹 서버가 포털서버로부터 가져온다. 이후, 포털서버에서 포털서버에 임시 저장된 time limit 이 있는 성공 토큰이나 사용자 아이디 및 실패메시지나 사용자 아이디를 삭제한다. 이후, 사용자단말기(200)가 고객사 웹 서버(100)에게 준 성공 토큰과 고객사 웹 서버(100)가 포털서버(300)로부터 가져온 성공 토큰의 비교가 사용자 아이디를 기준으로 일치한 경우에는 최종 성공을, 나머지의 경우에는 최종 실패를 결정하고 최종 성공 시 성공화면을 최종 실패 시 실패화면을 고객사 웹 서버가 사용자단말기(200)로 https를 활용해서 전송한다. 이후, 고객사 웹 서버(100)에서 등록 성공 시, 고객사 웹 서버에서 고객사 웹 서버(100) 전용 아이디와 본 기술의 사용자 아이디를 매칭시켜 고객사 웹 서버 DB에 이 매칭된 정보들을 저장하는 기능과. 고객사 웹 서버가 사용자단말기로 로그인화면을 보낼 때, 즉, 최초 로그인 화면을 전송시에, 고객사 웹 서버가 사용자단말기로 고객사 웹 서버 전용 포털서버의 포털서버 URL과 고객사 웹 서버의 고객사 웹 서버 URL 등의 정보를 포함해서 로그인 화면을 전송하는 기능을 갖는다. 여기서, 상기 고객사 웹 서버가 전용으로 사용하는 포털서버의 포털서버 URL 정보는 사용자단말기기가 등록데이터를 중계서버를 통해 고객사 웹 서버가 전용으로 사용하는 포털서버로　보내기 위해서 필요하거나, 사용자단말기가 인증정보를 포털서버로 보내기 위해서 인증정보 내에 해당 포털서버 URL 정보를 넣기 위해 필요하다.　따라서, 상기 등록데이터를 사용자단말기기가 중계서버로 보낼 때, 상기 포털서버 URL 정보도 사용자단말기가 중계서버로 같이 보낸다. 그리고, 상기 고객사 웹 서버가 사용자단말기에게 최초 로그인 화면과 함께 자신의　고객사 웹 서버 URL과 고객사 웹 서버가 전용으로 사용하는 포털서버의 포털서버 URL 을 같이 보내는데, 이때 사용자단말기가 고객사 웹 서버로부터 받은 해당 고객사 웹 서버 URL과 포털서버 URL의 정보들을, 사용자단말기가 인증정보를 만들어서 중계서버나 포털서버로 보낼 때, 인증정보 내에 포함시킬 목적으로 사용한다.

상기 사용자단말기가 상기 고객사 웹 서버로부터 고객사의 로그인 화면을 디스플레이 받고, 이 고객사 로그인 화면을 디스플레이 받을 때 사용자단말기가 상기 고객사 웹 서버로부터 고객사 웹 서버 URL 정보와 고객사 웹 서버가 전용으로 사용하는 포털서버의 포털서버 URL 정보도 같이 받는 기능과, 사용자단말기기에서 중계서버(relay server) 로 상기 포털서버 URL 정보와 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 https 로 전송하고, 이를 받은 중계서버에선 자신이 받은 상기 포털서버 URL 정보를 사용해서 자신이 받은　해당 등록데이터를 해당 포털서버로 전송하고, 이후, 사용자의 최초 등록 시에는, 상기 등록데이터 내 아이디(즉, 사용자의 이메일 주소+지역번호) 내의 지역번호에서 해당 지역번호가 상기 등록데이터를 받은 중계서버(400)와 맞지 않으면 프로세스를 중단한다. 이후, 중계서버(400)에서 등록데이터 내의 사용자 아이디의 유일성을 검증 후, 실패 시 프로세스를 중단하고, 이후, 중계서버(400)에서 상기 등록데이터의 전자서명을 검증한 후 저장하며, 실패 시 상기 등록데이터를 저장하지 않고 프로세스를 중단한다. 그리고, 사용자의 최초 등록 이후의 등록 및 인증, 탈퇴 시에는 중계서버(400)에 저장된 등록데이터와 사용자단말기(200)가 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭이 되더라도 서로를 해쉬 값으로 서로 비교한 후 불일치 시 프로세스를 중단하고, 이후, 최초 사용자 등록 및 최초 사용자 등록 이후의 등록, 인증, 탈퇴 시에는 상기 사용자단말기(200)로부터 중계서버가 받은 등록데이터를 중계서버(400)에 임시 저장하는 기능과, 상기 중계서버(400)로부터 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송받는 기능과, 사용자단말기(200)에서 중계서버(400)로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값을 shuffle 번호대로 shuffle 해서 중계서버로 https를 활용해서 전송한 후에, 중계서버(400)에서 shuffle 번호대로 복원해서 인증정보를 만든다. 복원 후, 인증정보내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 일치하지 않는 것이 하나라도 있으면 프로세스를 중단한다. 이후, 중계서버(400)에서 필요하다면 추가로 해당 인증정보의 전자서명을 검증받고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 않아도 된다. 이후, 이 인증정보와 중계서버(400)에 미리 임시 저장된 등록데이터와 비교시 아이디별 공개키들이 불일치 시 프로세스를 중단한다. 이후에, 해당 인증정보를 중계서버(400)에 임시 저장하는 기능과, 사용자단말기(200)에서 포털서버(SIDSL 서비스 서버)(300)로 상기 인증정보를 shuffle 번호대로 shuffle 해서 https로 전송하고 포털서버(300)에서 shuffle 번호대로 복원에 실패한 경우엔 해당 프로세스를 중단하고, 반대로 포털서버에서 복원에 성공해서 인증정보를 다시 만든 경우엔 다음을 진행한다.

이후, 이와 같이 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증을 수행한 후에, 이후, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버(400)를 통해 사용자단말기기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버(300)에서 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후에, 이 실패메시지와 사용자 아이디를 포털서버에서 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버(300) 자신이 중계서버(400)를 통해 사용자단말기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값 등의 데이터 중의 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 포털서버(300)에서 등록, 인증, 탈퇴를 임시 성공 처리한다. 이후, 상기 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔서 성공신호를 만들고 이를 중계서버(400)에서 보조 인증을 한 후에 성공 시, 포털서버에서 해당 등록, 인증, 탈퇴를 최종적으로 성공처리한다. 이후, 포털서버(300)에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버에 임시 저장하고, 이 time limit이 있는 성공 토큰과 사용자 아이디를 포털서버에서 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리, 상기 성공신호를 가지고 중계서버(400)에서 보조인증이 실패 시에는, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 실패 처리한다. 이후, 포털서버(300)에서 사용자 아이디와 실패메시지를 임시 저장한 후, 이들을 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 보내는 기능과, 상기 사용자단말기(200)는 해당 고객사 웹 서버(100)에게 사용자 아이디와 자신이 최초 로그인 화면에서 받은 웹 쿠키 또는 웹 세션아이디 및 성공 시에는 time limit 이 있는 성공 토큰을, 실패 시에는 실패메시지를 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버(100)에 문의한다. 이후, 고객사 웹 서버(100)는 해당 사용자 아이디를 포털서버(300)에게 https를 활용해서 문의하고 time limit 이 있는 성공 토큰이나 실패메시지를 사용자 아이디와 함께 고객사 웹 서버가 포털서버(300)로부터 가져온다. 이후, 사용자단말기(200)가 고객사 웹 서버(100)에게 준 성공 토큰과 고객사 웹 서버(100)가 포털서버(300)로부터 가져온 성공 토큰의 비교가 일치한 경우에는 최종 성공을, 나머지의 경우에는 최종 실패를 결정하고 최종 성공 시 성공화면을 최종 실패 시 실패화면을 고객사 웹 서버가 사용자단말기로 전송하는 기능과, 사용자단말기가 중계서버(400)로 등록데이터를 보낼 때 포털서버 URL 및 등록데이터를 같이 보내서 중계서버에서 해당 등록데이터를 해당 포털서버로 보내는 기능과, 사용자단말기가 포털서버로 인증정보를 보낼 때 사용자단말기가 고객사 웹 서버(100)로부터 최초 로그인 화면을 받을 시 같이 받은 포털서버 URL 을 활용해서 상기 인증정보를 해당 포털서버(300)로 보내는 기능과, 사용자단말기가 중계서버(400)로 등록데이터를 보낼 때 사용자단말기(200) 자신이 가지고 있는 등록데이터 내의 공개키 안의 중계서버 URL 정보를 활용해서 해당 중계서버로 보내는 기능과, 사용자단말기가 중계서버(400)로 인증정보를 보낼 때 사용자단말기(200) 자신이 가지고 있는 등록데이터 내의 공개키 안의 중계서버 URL 정보를 활용해서 해당 중계서버로 보내는 기능을 갖는 것이다.

상기 포털서버(SIDSL 서비스 서버)(300)는 중계서버(400)로부터 등록 데이터를 https로 전송받고 포털서버(300)에서 사용자 아이디, 난수, 이들의 해쉬 값을 중계서버(400)로 https를 활용해서 전송하는 기능과, 포털서버(300)는 상기 사용자단말기(200)로부터 인증정보를 shuffle 번호대로 shuffle 한 데이터를 https로 전송받고, 이를 다시 포털서버(300)에서 shuffle 번호대로 복원한 후에, 인증정보내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 일치하지 않는 것이 하나라도 있으면 프로세스를 중단한다.

인증정보가 복원 성공 검증된 경우 만약 포털서버(300)가 복원 성공 검증된 인증정보 내의 사용자 공개키를 이용하여 그 인증정보에 대한 전자서명 검증을 수행하도록 한다면 다음과 같은 문제점이 발생할 수 있다. 즉, 인증정보의 공개키가 해커의 공개키인 경우, 해커가 자신의 개인키로 전자서명을 하기 때문에 해당 인증정보에 대한 전자서명 검증은 당연히 통과되게 되어, 해커에 의하여 다음 과정이 계속 수행되게 되는 문제점이 있게 된다.

이후, 이와 같이 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증을 수행한 후에, 이 전자서명 검증이 실패하거나 상기 전자서명 검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버(400)를 통해 사용자단말기기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버(300)에서 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후에, 이 실패메시지와 사용자 아이디를 포털서버에서 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명 검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버(300) 자신이 중계서버(400)를 통해 사용자단말기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값 등의 데이터 중의 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 해당 등록, 인증, 탈퇴를 임시 성공으로 보고 상기 포털서버가 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버(300)에서 중계서버(400)로 shuffle 번호대로 shuffle 한 후에 VPN 이나 https를 활용해서 전송하고, 중계서버에서 shuffle 번호대로 다시 복원한다. 복원 시, 성공신호내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 일치하지 않는 것이 하나라도 있으면 프로세스를 중단한다. 이후, 포털서버(300)가 중계서버(400)로 VPN 이나 https를 활용해서 보낸 성공신호와 사용자단말기(200)가 중계서버(400)로 https를 활용해서 보내고 중계서버(400)에 임시 저장된 인증정보를 중계서버에서 서로 비교해서, shuffle 번호와 shuffle 번호 해쉬를 제외하고 모두가 다 서로 일치하고 해당 성공신호에 해당되는 중계서버(400)에서 사용자 최초 등록 시에 미리 저장된 등록데이터가 개인키 유출로 마킹된 것이 아니라면, 중계서버(400)에서 상기 성공신호와 인증정보를 비교하는 보조인증을 성공으로 설정하고 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호의 난수정보가 포함된 성공 메시지와 사용자 아이디를 보낸다. 또한, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에도 보조인증을 성공으로 설정하고 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이와 달리, 중계서버(400)에서 사용자단말기(200)가 중계서버(400)로 보내고 임시 저장된 등록데이터가 사용자 최초 등록 시에 미리 저장되어 있고 개인키 유출로 마킹이 되어 있는 등록데이터가 일치하고, 상기 성공신호와 중계서버(400)에 미리 임시 저장된 인증정보 및 중계서버(400)에 미리 임시 저장된 상기 등록데이터의 사용자 아이디 및 공개키들이 서로 일치하면 해커가 유출된 개인키로 해킹하는 것으로 보고 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호의 난수정보가 포함된 실패메시지와 사용자 아이디를 보낸다. 하지만, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 또한, 중계서버(400)에서 성공신호와 중계서버(400)에 미리 임시 저장된 인증정보를 사용자 아이디를 기준으로 비교해서 공개키 등이 서로 불일치할 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도로 보고 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호의 난수정보가 포함된 실패메시지와 사용자 아이디를 보낸다. 또한, 중계서버(400)에서 성공신호가 있으나 사용자 아이디를 기준으로 해당 중계서버에 임시 저장된 인증정보가 없다면 중계서버(400)를 우회 등록, 우회 인증, 우회 탈퇴하려는 해킹 시도로 보고 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 보낸다. 이후, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 포털서버(300)에서 사용자단말기(200)로부터 받은 전자서명 검증된 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 개인키 유출 사고로 마킹된 공개키로 해커가 등록, 인증을 하려고 했거나, 또는 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도, 또는 해커가 중계서버(400)를 우회 등록, 우회 인증, 또는 우회 탈퇴 하려는 시도로 보고 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고한다. 그리고, 상기에서 포털서버(300)에서 중계서버(400)로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받은 경우, 포털서버(300)에서 사용자단말기(200)로부터 받고 전자서명 검증된 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 탈퇴를 하려고 하는 시도로 보고 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 해당 사고내용을 보고한다. 이후, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 개인키 유출 사고의 등록, 인증의 경우 포털서버에서 최종적으로 등록, 인증 취소를 하고, 이와는 달리, 포털서버가 중계서버(400)로부터 성공메시지와 사용자 아이디를 받은 개인키 유출 사고의 탈퇴의 경우, 즉, 사용자 자신이나 해커의 탈퇴의 경우, 보조인증을 성공으로 보고, 포털서버(300)에서 해당 탈퇴를 최종적으로 진행한다. 이와는 달리, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 다른 공개키 등록, 인증, 탈퇴의 경우엔, 포털서버(300)에서 최종적으로 등록, 인증, 탈퇴 취소를, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 중계서버(400) 우회 해킹의 경우에는, 포털서버(300)에서 최종적으로 우회 등록, 우회 인증, 우회 탈퇴를 취소한다. 이후, 포털서버(300)가 중계서버(400)로부터 성공 메시지와 사용자 아이디를 받은 나머지의 경우, 즉, 보조인증 성공의 경우 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 성공 처리한다. 이후, 포털서버(300)에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버(300)에 임시 저장하고, 이 time limit 이 있는 성공 토큰과 사용자 아이디를 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 보낸다. 반대로, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 포털서버(300)에서 해당 사용자 아이디 및 상기 실패메시지를 임시 저장하고, 이들을 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 보내는 기능과, 포털서버가 중계서버(400)로 성공신호를 보낼 때 성공신호안의 공개키 안의 중계서버 URL 정보를 활용해서 해당 중계서버로 보내는 기능을 갖는다.

상기 중계서버(400)는 상기 사용자단말기(200)로부터 중계서버(relay server)(400)로 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 https로 전송받고, 사용자의 최초 등록 시에는, 상기 등록데이터의 사용자 아이디(즉, 사용자의 이메일 주소+지역번호) 내의 지역번호가 상기 등록데이터를 받은 중계서버(400)와 맞지 않으면 프로세스를 중단한다. 이후, 중계서버(400)에서 등록데이터 내의 사용자 아이디의 유일성을 검증 후, 실패 시 프로세스를 중단하고, 이후, 중계서버(400)에서 상기 등록데이터의 전자서명을 검증한 후 저장하며, 실패 시 상기 등록데이터를 저장하지 않고 프로세스를 중단한다. 그리고, 사용자의 최초 등록 이후의 등록, 인증, 및 탈퇴 시에는 중계서버(400)에 최초 등록 시 미리 저장된 등록데이터와 사용자단말기(200)가 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나, 매칭되는 것이 있더라도, 최초 등록시 미리 저장된 등록데이터를 해쉬값으로 만들고, 사용자단말기가 새로 보낸 등록데이터도 해쉬값으로 만든 후, 서로의 해쉬값들을 비교하여 해쉬값들이 서로 불일치하는 경우 사용자단말기로 실패메시지를 전송하고 프로세스를 중단한다.

이후에, 해커에 의해서 사용자의 자신의 개인키가 유출되었던 것으로, 즉, 개인키 유출 사고로 사용자가 스스로 판단하게 되면, 사용자는 중계서버의 관리자에게 연락해서 자신의 공개키를 포함하고 최초 등록 시에 미리 중계서버에 저장된 사용자의 등록데이터를 개인키 유출 사고로 마킹해 달라고 요청할 수 있다. 이로부터 관리자가 상기 사용자의 공개키를 포함한 등록데이터를 개인키 유출 사고로 마킹해 놓으면, 그 이후에 사용자단말기가 중계서버로 등록, 인증 또는 탈퇴 요청 등으로 등록데이터를 보낼 때, 개인키 유출 사고로 마킹해 놓은 등록데이터의 해쉬값과 사용자단말기가 중계서버로 보낸 등록데이터의 해쉬값이 서로 일치하더라도, 중계서버(400)는 이를 개인키 유출 사고에 해당하는 등록, 인증 또는 탈퇴 요청으로 판단하여, 개인키 유출 사고의 등록, 인증 요청인 경우에는 중계서버(400)가 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 개인키 유출 사고의 탈퇴 요청인 경우에는 다음 단계로 그대로 진행하게 된다.

이후, 최초 사용자 등록 및 최초 사용자 등록 이후의 등록, 인증, 탈퇴 시에는 상기 사용자단말기(200)로부터 받은 등록데이터를 중계서버(400)에 임시 저장하는 기능과, 포털서버(300)로 등록 데이터를 https로 전송하고 포털서버(300)로부터 사용자 아이디, 난수, 이들의 해쉬 값을 중계서버(400)로 https를 활용해서 전송받는 기능과, 중계서버(400)에서 상기 사용자단말기(200)로 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송하는 기능과, 사용자단말기(200)에서 중계서버(400)로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 데이터를 shuffle 번호대로 shuffle 해서 https로 전송한 후에, 중계서버(400)에서 shuffle 번호대로 복원 한다, 복원 시, 인증정보 내의 원본과 원본의 해쉬가 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 하나라도 불일치 시 프로세스를 중단한다. 이후, 중계서버(400)에서 필요하다면 추가로 해당 인증정보의 전자서명을 검증하고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 않아도 된다. 이후, 이 인증정보와 중계서버(400)에 미리 임시 저장된 등록데이터와 비교시 아이디별 공개키가 불일치 시 프로세스를 중단한다. 이후에, 해당 인증정보를 중계서버에 임시 저장하는 기능과, 사용자단말기가 고객사 웹 서버로부터 최초 로그인 화면을 받을 시 사용자단말기가 고객사 웹 서버로부터 함께 받은 포털서버 URL 정보를 사용해서, 사용자단말기가 shuffle 번호대로 shuffle 된 상기 인증정보를 상기 포털서버 URL 정보에 해당되는 포털서버(SIDSL 서비스 서버)로 https를 사용해서 전송하고 포털서버(300)에서 shuffle 번호대로 인증정보를 복원한 후, 복원이 실패 시에는 프로세스를 중단하고, 복원이 성공 시에는 다음 단계를 진행한다.

이후, 이와 같이 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증을 수행한 후에, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버(400)를 통해 사용자단말기기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버(300)에서 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후에, 이들을 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명 검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 중계서버(400)를 통해 사용자단말기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값 등의 데이터 중의 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 상기 포털서버(300)가 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버(300)에서 중계서버(400)로 shuffle 번호대로 shuffle 한 후에 VPN 이나 https를 활용해서 전송하고, 중계서버(400)에서 받은 후에는 받은 shuffle 번호대로 다시 복원한다. 복원 시, 성공신호 내의 원본과 원본의 해쉬가 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 하나라도 불일치 시 프로세스를 중단한다. 이후, 상기 성공신호에 해당되는 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 중계서버(400)에 미리 임시 저장된 인증정보가 중계서버(400)에 없을 경우 중계서버(400)에서 포털서버(300)로 상기 성공신호내의 난수정보를 포함한 실패메시지와 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 사용자단말기(200)가 포털서버(300)로 shuffle 번호대로 shuffle 보내고 포털서버(300)에서 shuffle 번호대로 복원하고 전자서명 검증된 상기 인증정보의 고객사 웹 서버(100) URL이 우회 등록, 우회 인증, 또는 우회 탈퇴 해킹당했다고 보고 포털서버(300)에서 해당 사용자에게 사고내용을 사용자 아이디의 이메일 주소를 활용해서 이메일로 전송한다. 이후, 포털서버(300)에서 최종적으로 해당 우회 등록, 우회 인증, 우회 탈퇴를 취소한다. 이와는 달리, 중계서버(400)에서 아이디를 기준으로 성공신호에 해당되는 중계서버(400)에 미리 임시 저장된 인증정보와 중계서버(400)에 미리 임시 저장된 등록데이터가 있지만, 중계서버(400)에서 성공신호의 공개키와 해당 인증정보의 공개키가 불일치하는 경우, 해커의 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹시도로 보고, 중계서버(400)에서 사용자 아이디를 기준으로 성공신호에 해당되는 중계서버(400)에 미리 임시 저장된 인증정보와 중계서버(400)에 미리 임시 저장된 등록데이터가 있고 사용자 아이디와 공개키 등이 서로 일치하지만, 사용자 아이디를 기준으로 상기 임시 저장된 등록데이터에 해당되고 사용자가 최초 등록 시에 미리 저장한 등록데이터가 개인키 유출로 마킹된 것이라면, 해커가 유출된 개인키로 해킹하는 개인키 유출 사고로 본다. 이 두 경우 다 중계서버(400)에서 포털사이트로 상기 성공신호내의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 하지만, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)가 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)가 포털서버(300)로 보내고 전자서명 검증된 해당 인증정보의 고객사 웹 서버(100) URL이 해킹된 것으로 보고, 즉, 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려고 하거나 개인키 유출 사고의 경우 해커가 유출된 개인키로 등록, 인증을 하려는 시도로 보고 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 각각의 사고 내용에 대한 이메일 전송을 포털서버(300)에서 한다. 그리고, 포털서버(300)가 중계서버(400)로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받은 보조인증의 성공의 경우, 사용자 자신이나 해커의 탈퇴 시도로 보고 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 해당 사고내용으로 이메일 전송을 포털서버(300)에서 한다. 이후, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 즉, 포털사이트에서 다른 공개키 등록, 인증, 탈퇴의 경우엔, 최종적으로 등록, 인증, 탈퇴 취소를 하고, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 개인키 유출 사고의 등록, 인증의 경우엔, 포털서버에서 최종적으로 등록, 인증 취소를 하고, 포털서버(300)에서 중계서버(400)로부터 성공 메시지와 사용자 아이디를 받은 개인키 유출 사고의 탈퇴의 경우, 즉, 사용자 자신 또는 해커의 탈퇴의 경우, 포털서버(300)에서 해당 탈퇴를 최종적으로 진행한다. 이와는 달리, 상기 포털서버(300)가 중계서버(400)에게 shuffle 번호대로 shuffle해서 VPN 이나 https로 보내고 중계서버(400)에서 shuffle 번호대로 복원에 성공한 성공신호와 사용자 아이디를 기준으로 해당 성공신호에 해당되는 사용자단말기(200)가 중계서버(400)로 shuffle 번호대로 shuffle 해서 https로 보내고 중계서버(400)에서 shuffle 번호대로 복원에 성공한 후에 중계서버(400)에 미리 임시 저장된 인증정보가 있고, 상기 성공신호와 상기 인증정보가 서로 shuffle 번호와 shuffle 번호 해쉬를 제외하고 일치할 경우, 그리고, 사용자 아이디를 기준으로 상기 성공신호에 해당되는 중계서버(400)에서 사용자의 최초 등록 시 미리 저장된 등록데이터가 개인키 유출로 마킹된 경우가 아니라면, 보조인증을 성공으로 보고, 포털서버(300)가 받은 상기 성공신호 내의 난수가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)에서 성공 메시지와 사용자 아이디를 받으면 최종적으로 등록, 인증, 탈퇴를 성공으로 처리한다. 하지만, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보의 아이디와 공개키가 상기 미리 임시 저장된 등록데이터와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키들이 서로 일치하는 후자의 경우엔 중계서버에서 사용자단말기로부터 받은 인증정보 내의 해당 고객사 웹 서버(100) URL에서 해커가 개인키 유출 사고로 마킹된 공개키로 등록 또는 인증을 하려고 하는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만, 개인키 유출 사고의 탈퇴의 경우 중계서버에서 해당 프로세스를 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키들이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키들이 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단한다.

다시 말해, 해커가 다른 사용자 아이디로 중계서버(400)를 통해 다른 공개키를 등록, 인증, 탈퇴하려고 할 시, 중계서버(400)에서 사용자 최초 등록 시에 미리 저장되어 있는 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 서명 값을 사용자단말기(200)가 중계서버(400)로 https를 활용해서 보낸 등록데이터나 인증정보와 비교해서 사용자 아이디 및 공개키들이 서로 불일치할 때도 탐지된다. 이때, 중계서버에서 사용자단말기가 새로 보낸 등록데이터와 사용자 최초 등록 시에 미리 저장되어 있는 등록데이터간의 사용자 아이디별 공개키 등의 비교가 불일치 시에는 해당 등록, 인증, 탈퇴 프로세스를 바로 중단하고, 상기 인증정보와 중계서버에 임시 저장된 등록데이터 간에 사용자 아이디별 공개키들의 비교가 불일치 시에는 해당 사고내용, 즉 해커의 다른 사용자의 다른 공개키 등록, 인증, 탈퇴 시도를 인증정보 내의 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 전송하고 프로세스를 종료시킬 수도 있다. 이외에도 포털서버(300)가 중계서버(400)에게 shuffle 번호대로 shuffle 한 후에 VPN 이나 https를 활용해서 보내고, 중계서버(400)에서 shuffle 번호대로 복원에 성공해서 해커의 중간자 공간자 공격이 없는 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 성공신호와 사용자 아이디를 기준으로 이 성공신호에 해당되는 중계서버(400)에 미리 임시 저장된 인증정보를 서로 비교해서 사용자 아이디별 공개키가 중계서버(400)에서 서로 불일치하면, 이것도 중계서버(400)를 활용해서 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹으로 탐지해서, 보조인증을 실패로 보고, 중계서버(400)에서 해당 포털서버(300)로 상기 성공신호 내의 난수정보를 포함한 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 보낸다. 이후, 상기 사용자가 포털서버(300)로 shuffle 해서 보내고 포털서버(300)에서 shuffle 번호대로 다시 복원에 성공해서, 중간자 공격이 없고 전자서명 검증된 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 인증정보 데이터를 활용해서 해당 고객사 웹 서버 URL이 해킹당했다고 보고 해당 포털서버(300)에서 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 해당 사고 내용, 즉, 해커가 다른 사용자의 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도를 이메일로 전송한다. 이후, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 실패 처리한다.

그리고 해커가 유출된 개인키로 해킹하는 개인키 유출 사고의 경우, 즉, 중계서버(400)를 이용해서 해커가 해킹된 개인키로 등록, 인증, 탈퇴 시, 사용자단말기(200)가 중계서버(400)로 https를 활용해서 보낸 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값과 사용자단말기(200)가 중계서버(400)로 shuffle 번호대로 shuffle 해서 https로 보내고 중계서버(400)에서 해당 shuffle 번호대로 다시 복원해서 성공한, 중간자 공격이 발생하지 않은 인증정보를 중계서버(400)에서 사용자의 최초 등록 시 미리 저장되어 있고 개인키 유출로 마킹되어 있는 등록데이터와 비교해서 사용자 아이디와 공개키 등이 서로 일치 시 개인키 유출 사고로 보고 해킹 탐지가 먼저 가능하다. 이때, 중계서버에서 사용자단말기가 새로 보낸 등록데이터와 사용자 최초 등록 시에 중계서버에 미리 저장되어 있고 개인키 유출로 마킹된 등록데이터간의 사용자 아이디 및 공개키들의 비교가 일치하는 개인키 유출 사고의 등록, 인증의 경우에는 해당 등록, 인증 프로세스를 바로 중단한다. 하지만, 중계서버에서 상기 인증정보와 임시 저장된 등록데이터 및 상기 사용자 최초 등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터 간에 사용자 아이디 및 공개키들의 비교가 일치하는 개인키 유출 사고의 등록, 인증의 경우에는, 해당 중계서버에서 해당 사고내용을 해당 사용자에게 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 전송하고 프로세스를 중단한다. 하지만, 상기에서 개인키 유출 사고의 탈퇴의 경우엔 해당 중계서버에서 해당 사고내용을 해당 사용자에게 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 전송하지 않고 해당 프로세스를 계속 진행한다. 이와는 달리, 중계서버(400)에서 임시 저장된 등록데이터가 사용자 최초 등록 시에 미리 저장되어 있고 개인키 유출로 마킹이 되어 있는 등록데이터와 일치하고, 중계서버(400)에서 상기 성공신호와 중계서버(400)에 미리 임시 저장된 인증정보 및 중계서버(400)에 미리 임시 저장된 상기 등록데이터의 공개키 등이 서로 일치하면, 해커가 유출된 개인키로 해킹하는 것으로 보고, 다시 말해서 보조인증 실패로 보고, 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호내의 난수정보가 포함된 실패메시지와 사용자 아이디를 보낸다. 하지만, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버에서 포털서버가 중계서버로부터 상기 실패메시지와 사용자 아이디를 받은 경우, 즉, 개인키 유출 사고의 등록, 인증의 경우, 포털서버(300)에서 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 개인키 유출 사고 시 해커의 등록, 인증, 시도를 전송한다. 이후, 포털서버(300)에서 개인키 유출 사고로 보고 포털서버(300)에서 최종적으로 해당 등록 및 인증을 실패 처리한다. 하지만, 포털서버에서 포털서버가 중계서버로부터 상기 성공 메시지와 사용자 아이디를 받은 경우, 즉, 개인키 유출 사고의 탈퇴의 경우, 포털서버에서 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 개인키 유출 사고 시 사용자 자신이나 해커의 탈퇴 시도를 전송한다. 이후, 개인키 유출 사고에서 사용자 자신 또는 해커의 탈퇴의 경우 포털서버(300)에서 해당 탈퇴를 최종적으로 진행하는 것을 포함한다.

여기서, 상기 중계서버(400)에서, 사용자단말기(200)가 중계서버(400)로 https를 활용해서 새로 보낸 등록데이터와 인증정보의 경우, 상기 새로 보낸 등록데이터와 사용자 최초 등록 시에 중계서버(400)에 미리 저장된 등록데이터를 비교해서 서로 불일치 시 사용자단말기가 중계서버로 새로 보낸 상기 등록데이터를 임시 저장하지 않고 프로세스를 중단하고, 상기 새로 보낸 인증정보와 중계서버에 임시 저장된 상기 등록데이터와 사용자 아이디별 공개키들을 서로 비교시 불일치한다면, 이때에도 사용자단말기가 중계서버로 보낸 상기 인증정보를 임시 저장하지 않고 프로세스를 중단한다. 이후, 중계서버(400)에서 포털서버(300)가 보낸 성공신호와 사용자단말기(200)가 보낸 인증정보 간에 아이디를 기준으로 shuffle 번호와 shuffle 번호 해쉬를 제외한 비교시 까지만 해당 상기 등록데이터와 상기 인증정보를 중계서버에 임시 저장하고, 중계서버에서 상기 성공신호와 상기 인증정보와의 비교가 끝나게 되면 중계서버에 임시 저장된 상기 등록데이터와 중계서버에 임시 저장된 상기 인증정보를 삭제 처리한다.

또한, 상기 포털서버(300)와 중계서버(400)에서 개인키 유출 사고 대응 및 이메일로 사고내용을 보내는 대응, 중계서버 우회 등록, 우회 인증, 우회 탈퇴 해킹사고 대응 및 이메일로 사고내용을 보내는 대응, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하는 해킹을 방어하고 이메일로 사고내용을 보내는 대응을 할 수 있는 것이다.

상술한 시스템에 의하면, 해커가 포털서버(300)로부터 난수를 직접 받아서 본 기술의 중계서버(400)를 거치지 않고 직접 포털서버(300)에 등록, 인증, 탈퇴하려는 시도, 즉 우회 해킹을 할 수 있는데, 이때 해커의 중계서버(400)의 우회 등록, 우회 인증, 우회 탈퇴는 포털서버(300)가 중계서버(400)에게 VPN 이나 https를 활용해서 성공신호를 shuffle 번호대로 shuffle 해서 보냈을 때 사용자 아이디를 기준으로 이 성공신호에 해당되는 임시 저장된 인증정보가 해당 중계서버(400)에 없기 때문에 탐지될 수 있다. 이때, 보조인증을 실패로 보고, 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 성공신호의 난수정보가 포함된 실패메시지와 사용자 아이디를 보낸다. 이후, 사용자단말기(200)가 shuffle 번호대로 shuffle 해서 포털서버(300)에 보내고 포털서버(300)에서 shuffle 번호대로 다시 원복한 후, 사용자 전자서명 검증이 된 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값의 데이터에서 해당 고객사 웹 서버(100) URL이 해킹됐다는 해당 사고 내용, 즉, 해커가 중계서버(400)를 우회하는 해킹인, 우회 등록, 우회 인증, 우회 탈퇴 시도를 포털서버(300)에서 사용자 아이디 내에 있는 이메일 주소를 활용해서 이메일로 해당 사고 내용을 전송한다. 이후, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 취소하게 된다.

또한, 중계서버(400)의 우회 해킹이 아니라면, shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값의 성공신호는 중계서버(400)에서 아이디를 기준으로 했을 시 해당 중계서버(400)에 임시 저장된 인증정보와 해당 중계서버(400)에 임시 저장된 등록데이터가 있어야 한다. 중계서버(400)에서 상기 성공신호와 해당하는 인증정보를 서로 비교해서 shuffle 번호와 shuffle 번호 해쉬를 제외하고 서로 일치하고 사용자 아이디를 기준으로 상기 성공신호에 해당되고 중계서버(400)에서 사용자의 최초 등록 시에 미리 저장된 등록데이터가 개인키 유출로 마킹된 것이 아니면, 보조인증 성공으로 보고, 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 보낸다. 또한, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에도 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이와는 달리, 상기 성공신호와 사용자 아이디를 기준으로 이 성공신호에 해당하는 중계서버(400)에서의 인증정보 및 사용자 아이디를 기준으로 상기 성공신호에 해당되는 중계서버에서의 임시 저장된 또는 미리 저장된 등록데이터들을 서로 비교해서 보조 인증이 실패 시, 즉, 상기 개인키 유출 사고에서 해커의 등록, 인증 시도, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도, 및 해커의 중계서버를 우회하는 우회 등록, 우회 인증, 우회 탈퇴의 경우에는 상기 성공신호 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 그리고, 포털서버(300)에서 성공 메시지와 아이디를 받은 경우 포털서버(300에서 해당 등록, 인증, 탈퇴를 최종적으로 성공 처리한다. 이후, 포털서버(300)에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버(300)에 임시 저장하고, 이 time limit이 있는 성공 토큰과 사용자 아이디를 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 반대로 포털서버(300)에서 실패메시지와 아이디를 받은 경우 포털서버(300)에서 해당 등록, 인증, 탈퇴를 최종적으로 취소한다. 이후, 포털서버(300)에서 사용자 아이디 및 상기 실패메시지를 임시 저장하고, 이 실패메시지와 사용자 아이디를 포털서버에서 사용자단말기(200)로 https를 활용해서 보낸다. 이후, 해당 사용자단말기(200)는 해당 고객사 웹 서버(100)에게 사용자 아이디와 자신이 최초 로그인 화면에서 받은 웹 쿠키 또는 웹 세션아이디 및 성공 시에는 상기 time limit이 있는 성공 토큰을, 실패 시에는 상기 실패메시지를 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버(100)에 https로 문의한다. 이후, 고객사 웹 서버(100)는 해당 사용자 아이디를 포털서버(300)에 https로 문의하고 성공 시 상기 time limit이 있는 성공 토큰을, 실패 시 상기 실패메시지를 포털서버로부터 사용자 아이디와 함께 가져온다. 이후, 포털서버에서 해당 time limit이 있는 성공 토큰 및 사용자 아이디를 또는 해당 실패메시지 및 사용자 아이디를 삭제한다. 이후, 고객사 웹 서버(100)에서 사용자단말기(200)로부터 받은 성공 토큰과 해당 포털서버(300)로부터 받은 성공 토큰이 일치 시 최종 성공을 나머지의 경우에는 최종 실패를 결정하고 최종 성공 시 성공화면을 최종 실패 시 실패화면을 고객사 웹 서버가 사용자단말기(200)로 https를 활용해서 전송하는 것이다. 하지만, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 새로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기(200)가 중계서버에 보낸 인증정보의 아이디와 공개키가 상기 미리 임시 저장된 등록데이터와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키가 서로 일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보 내의 해당 고객사 웹 서버(100) URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 등록 또는 인증을 하려고 하는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만, 개인키 유출 사고의 탈퇴의 경우 중계서버에서 해당 프로세스를 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키들이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키들이 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단한다.

상술한 바와 같이, 본 기술에서는 모든 네트워크 구간들에서 https가 필요하므로 https를 모든 네트워크 구간들에서 명시하였지만, 이는 상기 https만 한정되는 것이 아니고, 본 기술에서는 모든 네트워크 구간들에서 보다 상위개념인 SSL/TLS 통신도 허용되는 것이다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 일실시예에 따른 포털사이트 중계 서비스 제공하는 과정을 상세하게 설명한다.

도 1 내지 도 2에 도시한 바와 같이, 본 발명인 포털사이트 중계 서비스 제공 방법에 있어서, 등록 과정은 고객사 웹 서버(100)에서 사용자단말기(200)로 고객사의 로그인 화면이 https로 디스플레이 되게 하는 단계(a)와; 상기 사용자단말기(200)에서 중계서버(relay server)(400)로 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 https로 전송하고, 사용자의 최초 등록 시에는, 등록데이터 내 아이디(즉, 사용자의 이메일 주소+지역번호) 내의 지역번호와 해당 중계서버(400)가 맞지 않으면 프로세스를 중단한다. 이후, 중계서버(400)에서 등록데이터 내의 사용자 아이디의 유일성을 검증 후, 실패 시 프로세스를 중단하고, 이후, 중계서버(400)에서 등록데이터의 전자서명을 검증한 후 저장하며, 실패 시 등록데이터를 저장하지 않고 프로세스를 중단한다. 그리고, 사용자의 최초 등록 이후의 등록, 인증, 탈퇴에서는 중계서버(400)에서 사용자의 최초 등록 시에 미리 저장된 등록데이터와 사용자단말기(200)가 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭이 되더라도 서로를 해쉬값으로 비교한 후 불일치 시 프로세스를 중단하고, 이후, 사용자 최초 등록 시 또는 사용자 최초 등록 이후의 등록, 인증, 탈퇴의 경우 해당 등록데이터를 중계서버(400)에 임시 저장하는 단계(b)와; 상기 중계서버(400)에서 포털서버(300)로 등록 데이터를 https로 전송하는 단계(c)와; 상기 포털서버(300)에서 사용자 아이디, 난수, 이들의 해쉬 값을 중계서버(400)로 https를 활용해서 전송하는 단계(d)와; 상기 중계서버(400)에서 사용자단말기(200)로 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송하는 단계(e)와; 상기 사용자단말기(200)에서 중계서버(400)로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 데이터를 shuffle 번호대로 shuffle 해서 https로 전송한 후에, 중계서버(400)에서 shuffle 번호대로 복원한다. 이후, 인증정보 내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 하나라도 일치하지 않으면 프로세스를 중단한다. 이후, 중계서버(400)에서 필요한 경우 추가로 해당 인증정보의 전자서명을 검증하고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 않아도 된다. 이후, 이 인증정보와 중계서버(400)에서 상기 미리 임시 저장된 등록데이터와 비교시 아이디별 공개키 등이 불일치 시 프로세스를 중단한다. 이후, 해당 인증정보를 중계서버(400)에 임시 저장하는 단계(f)와; 상기 사용자단말기(200)에서 포털서버(SIDSL 서비스 서버)(300)로 상기 인증정보를 shuffle 번호대로 shuffle 한 후에 https를 활용해서 전송하는 단계(g)와; 상기 포털서버(300)에서 상기 인증정보를 shuffle 번호대로 복원한다. 이후, 인증정보 내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 하나라도 일치하지 않으면 프로세스를 중단한다.

이후, 이와 같이 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증을 수행한 후에, 이 전자서명검증이 실패하거나 상기 전자서명검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버(400)를 통해 사용자단말기기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버(300)에서 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후에, 이 실패메시지와 사용자 아이디를 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버 자신이 중계서버(400)를 통해 사용자단말기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값 등의 데이터 중의 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 상기 포털서버(300)에서 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버(300)에서 중계서버(400)로 shuffle 번호대로 shuffle 한 후에 VPN 이나 https를 활용해서 전송하고, 중계서버(400)에서 shuffle 번호대로 복원한다. 이후, 성공신호내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 하나라도 불일치 시 프로세스를 중단하는 단계(h)와; 상기 중계서버(400)에서 성공신호에 해당되는 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공의키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값에 해당되는 중계서버(400)에 미리 임시 저장된 인증정보가 없을 경우, 해커의 우회 등록, 우회 인증, 우회 탈퇴 시도라고 보고 중계서버(400)에서 포털서버(300)로 상기 성공신호 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 포털서버가 상기 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 받는다. 이후, 사용자단말기(200)가 shuffle 번호대로 shuffle 해서 포털서버(300)에게 보내고 포털서버(300)가 받아서 shuffle 번호대로 복원하고 전자서명 검증된 인증정보의 고객사 웹 서버(100) URL이 우회 등록, 우회 인증, 또는 우회 탈퇴 해킹당했다고 보고 포털서버(300)에서(300)에서 해당 사용자에게 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 해당 사고내용을 이메일로 전송한다. 이후, 해당 포털서버(300)에서 최종적으로 해당 우회 등록, 우회 인증, 우회 탈퇴를 취소하는 단계(i)와; 상기 중계서버(400)에서 사용자 아이디를 기준으로 했을 때 성공신호에 해당되는 임시 저장된 인증정보 및 해당 사용자의 임시 저장된 등록데이터가 있지만, 사용자 별 공개키가 서로 불일치하는 경우, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹시도로 보고, 중계서버(400)에서 사용자 아이디를 기준으로 성공신호에 해당되는 임시 저장된 인증정보와 임시 저장된 등록데이터가 있고 사용자 아이디와 공개키 등이 서로 일치하지만, 사용자 아이디를 기준으로 상기 임시 저장된 등록데이터에 해당되고 사용자가 최초 등록 시에 미리 저장한 등록데이터가 개인키 유출로 마킹된 것이라면, 해커나 사용자 자신이 유출된 개인키로 해킹하는 개인키 유출 사고로 본다. 이 두 경우 다, 중계서버(400)에서 포털서버(300)로 상시 성공신호내의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 보낸다. 하지만, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)가 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)로부터 포털서버(300)로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버(100) URL이 해킹당했다고 보고 해당 사용자에게 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 해커의 다른 사용자 아이디의 다른 공개키의 등록 시도 및 개인키 유출 사고 시 해커의 등록 시도를 전송한다. 그리고, 포털서버(300)가 중계서버(400)로부터 개인키 유출 사고 탈퇴 시의 성공 메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)로부터 포털서버(300)로 보내고 전자서명 검증된 인증정보의 내의 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 개인키 유출 사고 시 사용자 자신이나 해커의 탈퇴 시도를 전송한다. 이후, 포털서버(300)가 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)가 포털서버(300)로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버(100) URL이 해킹된 것으로 보고, 해당 포털서버(300)에서 해커의 다른 사용자의 다른 공개키 등록, 인증, 탈퇴의 경우 해당 등록을 최종적으로 취소하고 개인키 유출 사고 시 해커의 등록, 인증의 경우 해당 등록을 최종적으로 취소한다. 하지만, 상기에서 포털서버(300)가 중계서버(400)로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받은 경우, 즉, 개인키 유출 사고에서 사용자 자신 또는 해커의 탈퇴의 경우, 포털서버(300)에서 해당 탈퇴를 최종적으로 진행하는 단계(j)와; 상기 중계서버(400)에서 상기 성공신호와 상기 성공신호에 해당하는 중계서버(400)에 미리 임시 저장된 인증정보를 서로 비교해서 shuffle 번호와 shuffle 번호 해쉬를 제외하고 서로 일치하고 사용자 아이디를 기준으로 해당 성공신호에 해당되고 중계서버(400)에서 사용자의 최초 등록 시 미리 저장된 등록데이터가 개인키 유출로 마킹된 것이 아니라면, 즉 보조인증이 성공이라면 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호내에 있는 난수정보가 포함된 성공 메시지와 아이디를 전송한다. 또한, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에도, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이와는 달리, 상기 성공신호와 사용자 아이디를 기준으로 이 성공신호에 해당하는 중계서버(400)에 임시 저장된 해당 인증정보 및 중계서버(400)에 임시 저장된 해당 등록데이터 및 중계서버에 미리 저장된 해당 등록데이터를 서로 비교해서 보조 인증이 실패 시, 즉, 상기 개인키 유출 사고 시 해커의 등록, 인증의 경우, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도, 및 해커의 중계서버(400)를 우회하는 우회 등록, 우회 인증, 우회 탈퇴의 경우에는 상기 성공신호 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)에서 중계서버(400)로부터 성공 메시지와 사용자 아이디를 받았을 시에는, 즉, 보조인증 성공 중의 한 경우인 개인키 유출 사고의 탈퇴의 경우와 중계서버(400)의 나머지 보조 인증들이 성공 시에는, 전자의 경우, 사용자단말기(200)로부터 포털서버(300)가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버(100) URL에서 사용자나 해커가 개인키 유출 사고의 탈퇴를 하는 것으로 보고 포털서버가 받은 인증정보 내의 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 해당 사용자에게 사고 내용을 포털서버에서 전송한다. 후자의 경우, 포털서버에서 아무런 이메일 대응이 없다. 이후, 포털서버(300)에서 해당 등록을 최종적으로 성공처리 한다. 이후, 포털서버(300)에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버(300)에 임시 저장하고, 이 time limit이 있는 성공 토큰과 사용자 아이디를 각각 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 전송한다. 하지만 반대로, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받았을 시에는, 즉, 개인키 유출 사고의 등록 및 인증의 경우, 해커의 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도, 또는 해커가 중계서버(400)를 우회해서 우회 등록, 우회 인증, 우회 탈퇴 하려는 시도일 경우, 사용자단말기(200)로부터 포털서버(300)가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버(100) URL이 해킹당했다고 보고 포털서버가 받은 인증정보 내의 사용자의 아이디 내의 사용자의 이메일 주소를 활용해서 상기 해당 사고 내용을 이메일로 전송한다. 이후, 포털서버(300)에서 해당 등록을 최종적으로 실패 처리한다. 이후, 포털서버(300)에서 사용자 아이디와 상기 실패메시지를 임시 저장하고, 이 실패메시지와 사용자 아이디를 각각 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 전송한다. 하지만, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 새로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기(200)가 중계서버(400)에 새로 보낸 인증정보의 아이디와 공개키가 상기 미리 임시 저장된 등록데이터와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키들이 서로 일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보 내의 해당 고객사 웹 서버(100) URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 등록 또는 인증을 하려고 하는 시도로 보고, 중계서버(400)에서 중계서버가 받은 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만, 개인키 유출 사고의 탈퇴의 경우 중계서버에서 해당 프로세스를 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키들이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키들이 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단한다. 이때, 중계서버에서 상기 성공신호와 중계서버에 미리 임시 저장된 인증정보와 중계서버에 미리 임시 저장된 등록데이터와의 비교를 실행 후에는, 중계서버에서 임시 저장된 해당 인증정보 및 중계서버에서 임시 저장된 해당 등록데이터를 중계서버에서 삭제하는 단계(k)와; 해당 사용자단말기(200)는 해당 고객사 웹 서버(100)에게 자신이 최초 로그인 화면에서 받은 웹 쿠키나 웹 세션아이디 및 포털서버(300)로부터 받은 사용자 아이디와 성공 시에는 포털서버(300)로부터 받은 time limit 이 있는 상기 성공 토큰을, 실패 시에는 포털서버(300)로부터 받은 상기 실패메시지를 https를 활용해서 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버(100)에 문의한다. 이후, 고객사 웹 서버(100)는 해당 사용자 아이디를 포털서버(300)에게 https를 활용해서 문의하고 고객사 웹 서버가 포털서버로부터 상기 성공 토큰이나 실패메시지를 사용자 아이디와 함께 https로 가져온다. 이후, 포털서버에서 포털서버에 임시 저장된 time limit 이 있는 성공 토큰이나 사용자 아이디 및 실패메시지나 사용자 아이디를 삭제한다. 이후, 고객사 웹 서버(100)에서 자신이 사용자단말기(200)로부터 받은 성공 토큰과 포털서버(300)로부터 받은 성공 토큰이 사용자 아이디를 기준으로 일치할 경우 최종 성공을, 나머지 아닐 경우에 최종 실패를 결정한다. 이후, 최종 성공 시 성공화면을 최종 실패 시 실패화면을 고객사 웹 서버가 사용자단말기(200)로 https로 전송한다. 이때, 고객사 웹 서버(100)에서 등록 성공 시, 고객사 웹 서버에서 고객사 웹 서버(100) 전용 아이디와 본 기술의 사용자 아이디를 매칭시켜 고객사 웹 서버 DB에 이 매칭된 정보들을 저장하는 것을 특징으로 하는 단계(l);을 구비한다.

또한, 본 발명인 포털사이트 중계 서비스 제공 방법에 있어서, 인증 및 탈퇴 과정은 고객사 웹 서버(100)에서 사용자단말기(200)로 고객사의 로그인 화면이 디스플레이 되게 하는 단계(a)와; 상기 사용자단말기(200)에서 중계서버(relay server)(400)로 등록데이터인 사용자 아이디, 공개키, 이들의 사용자 전자서명 값을 https 로 전송하고, 중계서버(400)에서 사용자의 최초 등록 시에 미리 저장된 등록데이터와 사용자단말기(200)가 중계서버로 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭이 되더라도 서로를 해쉬값으로 비교한 후 불일치 시 프로세스를 중단한다. 이후, 해당 등록데이터를 중계서버(400)에 임시 저장하는 단계(b)와; 상기 중계서버(400)에서 포털서버(300)로 등록 데이터를 https로 전송하는 단계(c)와; 상기 포털서버(300)에서 사용자 아이디, 난수, 이들의 해쉬 값을 중계서버(400)로 https를 활용해서 전송하는 단계(d)와; 상기 중계서버(400)에서 사용자단말기(200)로 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송하는 단계(e)와; 상기 사용자단말기(200)에서 중계서버(400)로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 데이터를 shuffle 번호대로 shuffle 해서 https로 전송하고, 중계서버(400)에서 shuffle 번호대로 복원한다. 복원 시, 인증정보 내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 하나라도 불일치 시 프로세스를 중단한다. 다시 말해서, 중간자 공격이 탐지되면 프로세스를 중단한다. 이후, 중계서버(400)에서 필요시 추가로 해당 인증정보의 전자서명을 검증하고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 않아도 된다. 이후, 이 인증정보와 중계서버(400)에서 미리 임시 저장한 상기 등록데이터와 비교시 아이디별 공개키가 불일치 시에도 프로세스를 중단한다. 이후, 해당 인증정보를 중계서버(400)에 임시 저장하는 단계(f)와; 상기 사용자단말기(200)에서 포털서버(SIDSL 서비스 서버)(300)로 상기 인증정보를 shuffle 번호대로 shuffle 한 후에 https로 전송하는 단계(g)와; 상기 포털서버(300)에서 shuffle 번호대로 복원해서 중간자 공격이 없었음을 확인한 후, 즉 복원된 인증정보 내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본을 해쉬한 것들과 원본의 해쉬들이 서로 하나라도 불일치되는 것이 없다는 것을 확인한다.

이후, 이와 같이 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증을 수행한 후에, 이 전자서명검증이 실패하거나 상기 전자서명 검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버(400)를 통해 사용자단말기기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버(300)에서 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후에, 이 실패메시지와 사용자 아이디를 포털서버에서 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명 검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버(300) 자신이 보낸 사용자 아이디, 난수, 이들의 해쉬 값 등의 데이터 중의 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 상기 포털서버(300)가 사용자단말기로부터 받은 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버(300)에서 중계서버(400)로 shuffle 번호대로 shuffle 한 후에 VPN 이나 https를 활용해서 전송하고, 중계서버(400)에서 shuffle 번호대로 다시 복원한다. 복원 시, 성공신호 내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본들을 해쉬한 것들과 원본의 해쉬들이 하나라도 불일치 시 프로세스를 중단하는 단계(h)와; 상기 중계서버(400)에서 성공신호에 해당되는 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 중계서버(400)에서 미리 임시 저장한 인증정보가 없을 경우 중계서버(400)에서 포털서버(300)로 상기 성공신호의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 사용자단말기(200)에서 포털서버(300)로 shuffle 번호대로 shuffle 해서 보내고, 포털서버(300)에서 shuffle 번호대로 복원한 후 전자서명 검증된 인증정보의 고객사 웹 서버(100) URL이 우회 인증, 또는 우회 탈퇴 해킹당했다고 보고 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 해당 사용자에게 상기 사고 내용을 전송한다. 이후, 포털서버(300)에서 최종적으로 해당 우회 인증 또는 우회 탈퇴를 취소하는 단계(i)와; 상기 중계서버(400)에서 사용자 아이디를 기준으로 성공신호에 해당되는 임시 저장된 인증정보와 임시 저장된 등록데이터가 있지만, 사용자 아이디를 기준으로 성공신호의 사용자 공개키가 해당 인증정보 및 등록데이터의 사용자 공개키와 서로 불일치하는 경우, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹시도로 보고, 중계서버(400)에서 아이디를 기준으로 성공신호에 해당되는 임시 저장된 인증정보와 임시 저장된 등록데이터가 있고 사용자 아이디와 공개키 등이 서로 일치하지만, 사용자 아이디를 기준으로 상기 임시 저장된 등록데이터에 해당되고 사용자가 최초 등록 시에 미리 저장한 등록데이터가 개인키 유출로 마킹된 것이라면, 해커가 유출된 개인키로 해킹하는 개인키 유출 사고로 본다. 이 두 경우 다, 중계서버(400)에서 포털서버(300)로 상시 성공신호내의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 보낸다. 하지만, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)가 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)로부터 포털서버(300)로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버(100) URL이 해킹당했다고 보고 해당 사용자에게 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 해커의 다른 사용자의 다른 공개키를 활용한 인증, 탈퇴 시도 및 개인키 유출 사고 시 해커의 인증 시도를 전송한다. 그리고, 포털서버(300)가 중계서버(400)로부터 개인키 유출 사고 탈퇴 시의 성공 메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)로부터 포털서버(300)로 보내고 전자서명 검증된 인증정보의 내의 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 개인키 유출 사고 시 사용자 자신이나 해커의 탈퇴 시도를 전송한다. 이후, 포털서버(300)가 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)가 포털서버(300)로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버(100) URL이 해킹된 것으로 보고, 해당 포털서버(300)에서 다른 공개키 등록, 인증, 탈퇴의 경우 해당 인증, 탈퇴를 최종적으로 취소하고 개인키 유출 사고 시 해커의 등록, 인증의 경우 해당 인증을 최종적으로 취소한다. 하지만, 상기에서 포털서버(300)가 중계서버(400)로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받은 경우, 즉, 개인키 유출 사고에서 사용자 자신 또는 해커의 탈퇴의 경우, 포털서버(300)에서 해당 탈퇴를 최종적으로 진행하는 단계(j)와; 상기 중계서버(400)에서 상기 성공신호와 상기 성공신호에 해당하는 중계서버(400)에 미리 임시 저장된 인증정보를 서로 비교해서 shuffle 번호와 shuffle 번호 해쉬를 제외하고 서로 일치하고, 사용자 아이디를 기준으로 해당 성공신호에 해당되고 중계서버(400)에서 사용자의 최초 등록 시 미리 저장된 등록데이터가 개인키 유출로 마킹된 것이 아니라면, 보조인증을 성공이라고 보고, 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호내에 있는 난수정보가 포함된 성공 메시지와 아이디를 전송한다. 또한, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이와는 달리, 상기 성공신호와 이 성공신호에 해당하는 중계서버(400)에서 미리 임시 저장된 해당 인증정보 및 중계서버(400)에서 미리 임시 저장된 해당 등록데이터 및 중계서버에서 미리 저장된 등록데이터를 서로 비교해서 보조 인증이 실패 시, 즉, 상기 개인키 유출 사고 시 해커의 등록, 인증의 경우, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도, 및 해커의 중계서버(400)를 우회하는 우회 등록, 우회 인증, 우회 탈퇴의 경우에는 상기 성공신호 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)에서 중계서버(400)로부터 성공 메시지와 사용자 아이디를 받았을 시에는, 즉, 보조인증 성공의 한 경우인 개인키 유출 사고의 탈퇴의 경우와 중계서버(400)에서의 나머지 보조인증의 성공 시에는, 전자의 경우, 사용자단말기(200)로부터 포털서버(300)가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버(100) URL에서 사용자나 해커가 개인키 유출 사고의 탈퇴를 하는 것으로 보고 인증정보 내의 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 해당 사용자에게 사고 내용을 포털서버에서 전송한다. 후자의 경우, 포털서버에서 아무런 이메일 대응이 없다. 이후, 포털서버(300)에서 해당 인증, 탈퇴를 최종적으로 성공처리 한다. 이후, 포털서버(300)에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버(300)에 임시 저장하고, 이 time limit이 있는 성공 토큰과 사용자 아이디를 각각 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 전송한다. 하지만 반대로, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받았을 시에는, 즉, 개인키 유출 사고의 등록 및 인증의 경우, 해커의 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도, 또는 해커가 중계서버(400)를 우회해서 우회 등록, 우회 인증, 우회 탈퇴 하려는 시도일 경우, 사용자단말기(200)로부터 포털서버(300)가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버(100) URL이 해킹당했다고 보고 사용자의 아이디 내의 사용자의 이메일 주소를 활용해서 상기 해당 사고 내용을 이메일로 포털서버에서 전송한다. 이후, 포털서버(300)에서 해당 인증, 탈퇴를 최종적으로 실패 처리한다. 이후, 포털서버(300)에서 사용자 아이디와 상기 실패메시지를 임시 저장하고, 이 실패메시지와 사용자 아이디를 각각 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 전송한다. 하지만, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보의 사용자 아이디와 공개키가 상기 미리 임시 저장된 등록데이터의 사용자 아이디와 공개키와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자 아이디를 기준으로 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키들이 서로 일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보 내의 해당 고객사 웹 서버(100) URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 등록 또는 인증을 하려고 하는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만, 개인키 유출 사고의 탈퇴의 경우 중계서버에서 해당 프로세스를 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키 등이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키들이 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 인증, 탈퇴하려는 해킹 사고로 보고 해당 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해의 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단한다. 이때, 중계서버에서 상기 성공신호와 중계서버에 미리 임시 저장된 인증정보와 중계서버에 미리 임시 저장된 등록데이터와의 비교를 실행 후에는, 중계서버에서 임시 저장된 해당 인증정보 및 중계서버에서 임시 저장된 해당 등록데이터를 중계서버에서 삭제하는 단계(k)와; 해당 사용자단말기(200)는 해당 고객사 웹 서버(100)에게 자신이 최초 로그인 화면에서 받은 웹 쿠키나 웹 세션아이디 및 포털서버(300)로부터 받은 사용자 아이디 및 성공 시에는 포털서버(300)로부터 받은 time limit 이 있는 상기 성공 토큰을, 실패 시에는 포털서버(300)로부터 받은 상기 실패메시지를 https를 활용해서 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버(100)에 문의한다. 이후, 고객사 웹 서버(100)는 해당 아이디를 포털서버에 https를 활용해서 문의하고 상기 time limit이 있는 성공 토큰이나 실패메시지를 사용자 아이디와 함께 고객사 웹 서버가 포털서버로부터 가져온다. 이후, 포털서버에서 포털서버에 임시 저장된 time limit 이 있는 성공 토큰이나 사용자 아이디 및 실패메시지나 사용자 아이디를 삭제한다. 이후, 고객사 웹 서버(100)에서 자신이 사용자단말기(200)로부터 받은 time limit이 있는 성공 토큰과 포털서버(300)로부터 받은 time limit이 있는 성공 토큰이 일치할 경우 최종 성공을, 나머지 아닐 경우에 최종 실패를 결정한다. 이후, 최종 성공 시 성공화면을 최종 실패 시 실패화면을 고객사 웹 서버가 사용자단말기(200)로 https를 활용해서 전송하는 단계(l);을 구비한다.

상기 본 발명인 포털사이트 중계 서비스 제공 방법을 구성하는 각 기술적 단계들의 내용을 설명하면 다음과 같으며, 등록 과정과, 인증 및 탈퇴 과정에서 중복되는 내용은 기재를 생략한다.

첫째로는, 포털서버의 로그인 화면 단계(a)로서, 고객사 웹 서버(100)에서 사용자단말기(200)로 고객사의 로그인 화면이 디스플레이 되게 하는 것이다.

둘째로는, 등록데이터 전송과 중계서버에서 전자서명을 검증 저장 및 프로세스를 중단하는 단계(b)로서, 상기 사용자단말기(200)에서 중계서버(relay server)(400)로 등록데이터인 사용자 아이디, 공개키, 이들의 전자서명 값을 https로 전송하고, 사용자의 최초 등록 시에는, 등록데이터 내 사용자 아이디(즉, 사용자의 이메일 주소+지역번호) 내의 지역번호가 해당 중계서버(400)와 맞지 않으면 프로세스를 중단한다. 이후, 중계서버(400)에서 등록데이터 내의 사용자 아이디의 유일성을 검증 후, 실패 시 프로세스를 중단하고, 이후, 중계서버(400)에서 상기 등록데이터의 전자서명을 검증한 후 저장하며, 실패 시 상기 등록데이터를 저장하지 않고 프로세스를 중단한다. 그리고, 사용자의 최초 등록 이후의 등록 및 인증, 탈퇴에서는 중계서버(400)에 사용자의 최초 등록 시 미리 저장된 등록데이터와 사용자단말기(200)가 새로 보낸 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나 매칭되는 것이 있더라도, 최초 등록시 미리 저장된 등록데이터를 해쉬값으로 만들고, 사용자단말기가 새로 보낸 등록데이터도 해쉬값으로 만든 후, 서로의 해쉬값들을 비교하여 해쉬값들이 서로 불일치하는 경우 사용자단말기로 실패메시지를 전송하고 프로세스를 중단한다.

이후, 마지막으로 사용자의 최초 등록 시 또는 사용자의 최초 등록 이후의 등록, 인증, 탈퇴 시 해당 등록데이터를 중계서버(400)에 임시 저장한다.

셋째로는, 등록 데이터 전송 단계(c)로서, 상기 중계서버(400)에서 포털서버(300)로 등록 데이터를 https로 전송하는 것이다.

넷째로는, 포털서버(300)에서 사용자 아이디, 난수, 이들의 해쉬 값을 중계서버(400)로 전송 단계(d)로서, 상기 포털서버(300)에서 사용자 아이디, 난수, 이들의 해쉬 값을 중계서버(400)로 https를 활용해서 전송하는 것이다.

다섯째로는, 사용자 아이디, 난수, 이들의 해쉬 값을 사용자단말기로 전송하는 단계(e)로서, 상기 중계서버(400)에서 사용자단말기(200)로 사용자 아이디, 난수, 이들의 해쉬 값을 https로 전송하는 것이다.

여섯째로는, 인증정보를 shuffle 번호대로 shuffle 해서 사용자단말기(200)에서 중계서버(400)로 전송 및 중계서버(400)에서 shuffle 번호대로 복원하고 필요시 추가로 중계서버에서 해당 인증정보의 전자서명을 검증하고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 않아도 되는 단계(f)로서, 상기 사용자단말기(200)에서 중계서버(400)로 인증정보인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 데이터를 shuffle 번호대로 shuffle 해서 https로 보내고, 중계서버(400)에서 shuffle 번호대로 복원한다. 복원 시, 인증정보 내의 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들을 비교할 때 서로 하나라도 불일치 시, 프로세스를 중단한다. 이후, 중계서버(400)에서 필요시 추가로 해당 인증정보의 전자서명을 검증하고 검증 실패 시 해당 프로세스를 중단하고, 필요하지 않다면 중계서버에서 해당 인증정보의 전자서명을 검증하지 않아도 된다. 이후, 이 인증정보와 중계서버(400)에 상기 미리 임시 저장된 등록데이터와 비교시 사용자 아이디별 공개키들이 서로 불일치 시 사용자단말기(200)로 실패메시지를 전송한 후에 프로세스를 중단한다. 이후에, 해당 인증정보를 중계서버(400)에 임시 저장한다.

여기서, 나중에 포털서버(300)에서 중계서버(400)로 보낸 성공신호와 사용자단말기(200)가 중계서버(400)로 보낸 인증정보 간의 shuffle 번호와 shuffle 번호 해쉬를 제외한 비교가 실행된 후, 중계서버(400)에서 미리 임시 저장된 등록데이터와 중계서버(400)에서 미리 임시 저장된 인증정보를 삭제한다.

일곱째로는, 인증정보를 전송하는 단계(g)로서, 상기 사용자단말기(200)에서 포털서버(SIDSL 서비스 서버)(300)로 인증정보를 shuffle 번호대로 shuffle 해서 https로 전송하는 것이다.

여덟째로는, 포털서버(300)에서 상기 인증정보를 shuffle 번호대로 복원하고 전자서명을 검증 후에, 포털서버(300) 자신이 중계서버를 통해서 사용자단말기로 보낸 사용자 아이디, 난수, 이들의 해쉬값의 데이터 중의 사용자 아이디와 난수가 상기 포털서버가 사용자단말기로 받은 인증정보 내의 사용자 아이디, 난수와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하는 지의 검증 후, 실패 시, 포털서버(300)에서 사용자단말기(400)로 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 https를 활용해서 보낸다. 이와는 달리 성공 시, 상기 인증정보에서 shuffle 번호와 shuffle 번호 해쉬값만 바꿔서 성공신호를 만들고 이를 shuffle 번호대로 다시 shuffle 해서 중계서버(400)로 VPN 이나 https를 활용해서 다시 전송하는 단계(h)로서, 상기 포털서버(300)에서 사용자단말기(200)로부터 shuffle 번호대로 shuffle 된 인증정보를 https로 받고, 이를 포털서버(300)에서 다시 shuffle 번호대로 복원한 후에, 복원 성공을 검증해서 중간자 공격이 없었다는 것을 확인한다. 즉, 복원된 인증정보 내의 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들이 서로 불일치되는 것이 하나도 없음을 검증한다. 실패시 프로세스를 중단한다.

인증정보가 복원성공 검증된 경우, 만약 포털서버(300)가 복원 성공 검증된 인증정보 내의 사용자 공개키를 이용하여 그 인증정보에 대한 전자서명 검증을 수행하도록 한다면 다음과 같은 문제점이 발생할 수 있다. 즉, 인증정보의 공개키가 해커의 공개키인 경우, 해커가 자신의 개인키로 전자서명을 하기 때문에 해당 인증정보에 대한 전자서명 검증은 당연히 통과되게 되어, 해커에 의하여 다음 과정이 계속 수행되게 되는 문제점이 있게 된다.

이후, 이와 같이 중계서버(400)에 문의하여 중계서버(400)로부터 수신한 공개키를 이용하여 해당 인증정보를 전자서명 검증을 수행한 후에, 이 전자서명 검증이 실패하거나 상기 전자서명 검증이 성공해도 해당 인증정보 내의 사용자 아이디와 난수 데이터들을 포털서버 자신이 중계서버(400)를 통해 사용자단말기기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당 되는 데이터와 사용자 아이디를 기준으로 매칭시켰을 때 해당 난수들이 서로 일치하지 않아 실패 시, 포털서버(300)에서 최종적으로 해당 등록, 인증, 탈퇴를 실패처리한 후에, 포털서버(300)에서 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후에, 이 실패메시지와 사용자 아이디를 포털서버에서 사용자단말기(200)로 https를 활용해서 보낸다. 이와는 달리 상기 인증정보의 전자서명 검증이 성공하고 상기 인증정보 내의 사용자 아이디와 난수 데이터가 포털서버(300) 자신이 중계서버(400)를 통해 사용자단말기(200)로 보낸 사용자 아이디, 난수, 이들의 해쉬 값 등의 데이터 중의 사용자 아이디 및 난수와 서로 일치하는 지 확인한 후, 성공 시, 포털서버(300)에서 사용자단말기(400)로부터 받은 상기 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 성공신호를 만든다. 이 성공신호를 포털서버(300)에서 중계서버(400)로 shuffle 번호대로 shuffle 한 후에 VPN 이나 https를 활용해서 전송하고, 중계서버(400)에서 shuffle 번호대로 복원한다. 복원 시, 성공신호 내의 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들이 서로 하나라도 불일치 시 프로세스를 중단한다.

아홉째로는, 중계서버(400)에서 성공신호가 포털서버로 부터 shuffle 번호대로 shuffle 돼서 왔는데, 중계서버(400)에서 shuffle 번호대로 복원 후, 이 성공신호에 해당되는 사용자단말기(200)가 보낸 인증정보가 없는 경우, 중계서버(400)를 우회해서 우회 등록, 우회 인증, 우회 탈퇴를 하려는 해커의 의도로 보고, 포털서버(300)에서 상기 인증정보의 고객사 웹 서버(100) URL를 해킹된 사이트로 보고 사고 대응 및 이메일 전송하는 단계(i)로서, 중계서버(400)에서 성공신호가 포털서버(300)로부터 shuffle 번호대로 shuffle 되서 VPN 이나 https를 활용해서 왔는데, 중계서버(400)에서 shuffle 번호대로 복원 후, 이 성공신호에 해당되는 사용자단말기(200)가 중계서버(400)로 미리 보내고 중계서버(400)에 미리 임시 저장된 인증정보가 없을 경우 해커의 우회 등록, 우회 인증, 우회 탈퇴로 보고 중계서버(400)에서 포털서버(300)로 상기 성공신호의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 사용자단말기(200)가 포털서버(300)로 shuffle 번호대로 shuffle 해서 보내고 포털서버(300)에서 shuffle 번호대로 복원된 후 전자서명 검증된 상기 인증정보의 고객사 웹 서버(100) URL이 중계서버 우회 등록, 우회 인증, 또는 우회 탈퇴 해킹당했다고 보고 해당 사용자에게 사용자 아이디 내의 사용자 이메일 주소를 활용해서 해당 사고내용을 포털서버(300)에서 이메일로 전송한다. 이후, 포털서버(300)에서 최종적으로 해당 우회 인증, 우회 등록, 우회 탈퇴를 취소한다.

열 번째로는, 중계서버(400)에서 성공신호가 포털서버(300)로부터 shuffle 번호대로 shuffle 돼서 왔는데, 중계서버(400)에서 shuffle 번호대로 복원 후, 이 성공신호에 해당되는 사용자단말기(200)가 중계서버(400)로 보내고 중계서버(400)에서 미리 임시 저장된 해당 인증정보가 있지만, 중계서버(400)를 활용해서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려고 하거나, 개인키 유출 사고로 해커가 유출된 개인키로 중계서버(400)를 활용해서 등록, 인증, 탈퇴를 하려는 경우, 포털서버(300)에서 상기 인증정보의 고객사 웹 서버(100) URL를 해킹된 사이트로 보고 이메일 전송 및 사고 대응하는 단계(j)로서, 상기 포털서버(300)에서 성공신호를 shuffle 번호대로 shuffle한 후에 VPN 이나 https를 활용해서 중계서버(400)로 보내고 이후 중계서버(400)에서 상기 성공신호를 shuffle 번호대로 원복했을 때, 사용자 아이디를 기준으로 상기 원복된 성공신호에 해당되는 사용자단말기(200)에서 중계서버(400)로 shuffle 번호대로 shuffle해서 보내고 중계서버(400)에서 shuffle 번호대로 원복된 후 미리 임시 저장된 인증정보와 사용자단말기(200)에서 중계서버(400)로 보내고 미리 임시 저장된 해당 등록데이터가 있지만, 이 성공신호와 이에 해당하는 중계서버(400)에 임시 저장된 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 경우, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹시도로 보고, 중계서버(400)에서 사용자 아이디를 기준으로 성공신호에 해당되는 임시 저장된 인증정보와 임시 저장된 등록데이터가 있고 사용자 아이디와 공개키 등이 서로 일치하지만, 사용자 아이디를 기준으로 상기 임시 저장된 등록데이터에 해당되고 사용자가 최초 등록 시에 미리 저장한 등록데이터가 개인키 유출로 마킹된 것이라면, 해커나 사용자가 유출된 개인키로 해킹하는 개인키 유출 사고로 본다. 이 두 경우 다, 중계서버(400)에서 포털서버(300)로 상시 성공신호내의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 보낸다. 하지만, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)가 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)로부터 포털서버(300)로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버(100) URL이 해킹당했다고 보고 해당 사용자에게 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 사고 내용, 즉, 다른 공개키의 등록, 인증, 탈퇴 시도 및 개인키 유출 사고 시 해커의 등록, 인증 시도를 전송한다. 그리고, 포털서버(300)가 중계서버(400)로부터 개인키 유출 사고 탈퇴 시의 성공 메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)로부터 포털서버(300)로 보내고 전자서명 검증된 인증정보의 내의 고객사 웹 서버(100) URL이 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴 시도를 했다고 보고, 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 이메일로 해당 사고 내용, 즉, 개인키 유출 사고 시 사용자 자신이나 해커의 탈퇴 시도를 전송한다. 이후, 포털서버(300)가 중계서버(400)로부터 실패메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)가 포털서버(300)로 보내고 전자서명 검증된 인증정보의 고객사 웹 서버(100) URL이 해킹된 것으로 보고, 해당 포털서버(300)에서 다른 공개키 등록, 인증, 탈퇴의 경우 해당 등록, 인증, 탈퇴를 최종적으로 취소하고, 개인키 유출 사고 시 해커의 등록, 인증의 경우 해당 등록, 인증을 최종적으로 취소한다. 하지만, 상기에서 포털서버(300)가 중계서버(400)로부터 개인키 유출 사고의 탈퇴 성공 메시지와 사용자 아이디를 받은 경우, 즉, 개인키 유출 사고에서 사용자 자신 또는 해커의 탈퇴의 경우, 포털서버(300)에서 해당 탈퇴를 최종적으로 진행한다.

열한 번째로는, 상기 중계서버에서 포털서버로부터 중계서버가 받은 성공신호와 중계서버에 미리 임시 저장된 인증정보 및 중계서버에 미리 임시 저장된 등록데이터 및 중계서버에 사용자 최초 등록 시에 미리 저장된 등록데이터를 서로 비교해서 보조인증의 성공 유무를 판단하고 해당 결과를 상기 중계서버에서 포털서버로 전달하고, 해당 포털서버가 해당 결과를 다시 사용자단말기로 전달하는 단계(k)로서, 상기 중계서버(400)에서 상기 성공신호와 상기 성공신호에 해당하는 중계서버(400)에 미리 임시 저장된 인증정보를 서로 비교해서 shuffle 번호와 shuffle 번호 해쉬를 제외하고 서로 일치하고 해당 성공신호에 해당되고 중계서버(400)에서 사용자의 최초 등록 시 미리 저장된 등록데이터가 개인키 유출로 마킹된 것이 아니라면, 보조인증을 성공으로 보고, 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 상기 성공신호 내에 있는 난수정보가 포함된 성공 메시지와 사용자 아이디를 전송한다. 또한, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에도, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이와는 달리, 상기 성공신호와 사용자 아이디를 기준으로 이 성공신호에 해당하는 중계서버(400)에 임시 저장된 해당 인증정보 및 중계서버(400)에 임시 저장된 해당 등록데이터 및 중계서버에 사용자 최초 등록 시에 미리 저장된 등록데이터를 서로 비교해서 보조 인증이 실패 시, 즉, 상기 개인키 유출 사고 시 해커의 등록, 인증의 경우, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 시도, 및 해커의 중계서버(400)를 우회하는 우회 등록, 우회 인증, 우회 탈퇴의 경우에는 상기 성공신호 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)에서 중계서버(400)로부터 성공 메시지와 사용자 아이디를 받았을 시에는, 즉, 보조인증 성공 중의 한 경우인 개인키 유출 사고의 탈퇴의 경우와 중계서버(400)의 나머지 보조 인증들이 성공 시에는, 전자의 경우, 사용자단말기(200)로부터 포털서버(300)가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버(100) URL에서 사용자나 해커가 개인키 유출 사고의 탈퇴를 하는 것으로 보고 인증정보 내의 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 포털서버에서 해당 사용자에게 사고 내용을 전송한다. 후자의 경우, 포털서버에서 아무런 이메일 대응이 없다. 이후, 포털서버(300)에서 해당 등록, 인증, 탈퇴를 최종적으로 성공처리 한다. 이후, 포털서버(300)에서 time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버(300)에 임시 저장하고, 이 time limit이 있는 성공 토큰과 사용자 아이디를 각각 포털서버(300)에서 사용자단말기(400)로 https를 활용해서 전송한다. 하지만 반대로, 포털서버(300)에서 중계서버(400)로부터 실패메시지와 사용자 아이디를 받았을 시에는, 즉, 개인키 유출 사고의 등록 및 인증의 경우, 해커의 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도, 또는 해커가 중계서버(400)를 우회해서 우회 등록, 우회 인증, 우회 탈퇴 하려는 시도일 경우, 사용자단말기(200)로부터 포털서버(300)가 받고 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버(100) URL이 해킹당했다고 보고 사용자의 아이디 내의 사용자의 이메일 주소를 활용해서 상기 해당 사고 내용을 포털서버에서 이메일로 전송한다. 이후, 포털서버(300)에서 해당 등록, 인증, 탈퇴를 최종적으로 실패 처리한다. 이후, 포털서버(300)에서 사용자 아이디와 상기 실패메시지를 임시 저장하고, 이 실패메시지와 사용자 아이디를 각각 포털서버(300)에서 사용자단말기(200)로 https를 활용해서 전송한다. 하지만, 상기 성공신호 전에 사용자단말기(200)에서 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 사용자 아이디를 기준으로 서로 일치 시, 또는 사용자단말기(200)에서 중계서버(400)로 보낸 인증정보의 아이디와 공개키가 사용자 아이디를 기준으로 중계서버에서 상기 미리 임시 저장된 등록데이터와 일치하고 상기 미리 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 사용자 아이디를 기준으로 서로 일치 시, 개인키 유출 사고로 보고, 개인키 유출 사고의 등록, 인증에 있어서 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키가 서로 일치하는 후자의 경우엔 중계서버(400)에서 중계서버가 사용자단말기(200)로부터 받은 인증정보 내의 해당 고객사 웹 서버(100) URL에서 사용자 자신이나 해커가 개인키 유출 사고로 마킹된 공개키로 등록 또는 인증을 하려고 하는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용으로 해킹 보고하고 해당 프로세스를 중단한다. 하지만, 개인키 유출 사고의 탈퇴의 경우 해당 프로세스를 중계서버에서 이메일 보고 없이 그냥 진행한다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키들이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키들이 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단한다. 이후, 중계서버에서 상기 성공신호와 중계서버에 미리 임시 저장된 인증정보와 중계서버에 미리 임시 저장된 등록데이터와의 비교를 실행 후에는, 중계서버에서 임시 저장된 해당 인증정보 및 중계서버에서 임시 저장된 해당 등록데이터를 중계서버에서 삭제한다.

열두 번째로는, 성공 화면으로 이동하게 하는 단계(l)로서, 사용자단말기(200)는 해당 고객사 웹 서버(100)에게 자신이 최초 로그인 화면에서 받은 웹 쿠키나 웹 세션아이디 및 포털서버(300)로부터 받은 사용자 아이디 및 성공 시에는 포털서버(300)로부터 받은 상기 time limit이 있는 성공 토큰을, 실패 시에는 포털서버(300)로부터 받은 상기 실패메시지를 https로 주면서 등록, 인증, 탈퇴의 성공 여부를 고객사 웹 서버(100)에 최종 문의한다. 이후, 고객사 웹 서버(100)는 해당 사용자 아이디를 포털서버(300)에 https로 문의하고, 고객사 웹 서버는 포털서버(300)로부터 상기 아이디에 해당되는 상기 time limit 이 있는 성공 토큰이나 상기 실패메시지를 사용자 아이디와 함께 https로 가져온다. 이후, 포털서버에서 상기 time limit 이 있는 성공 토큰와 사용자 아이디를 또는 상기 실패메시지와 사용자 아이디를 삭제한다. 이후, 고객사 웹 서버(100)에서 자신이 사용자단말기(200)로부터 받은 성공 토큰과 고객사 웹 서버가 포털서버(300)로부터 받은 성공 토큰이 사용자 아이디를 기준으로 일치하는 경우에는 최종 성공을, 다른 경우들에 있어선 최종 실패를 결정하고 최종 성공 시 성공화면을 최종 실패 시 실패화면을 고객사 웹 서버가 사용자단말기(200)로 https를 활용해서 전송하는 것이다. 이때, 고객사 웹 서버(100)에서 등록 성공 시, 고객사 웹 서버에서 고객사 웹 서버(100) 전용 아이디와 본 기술의 사용자 아이디를 매칭시켜 고객사 웹 서버 DB에 이 매칭된 정보들을 저장한다.

도 2에 도시한 바와 같이, 사용자 아이디 아키텍쳐를 살펴보면, (1) 사용자 아이디는 기본적으로 사용자의 이메일 주소와 지역번호를 사용하고, 이메일 주소 뒤에 붙는 지역번호는 사용자 전용 중계서버(400)를 의미한다. (2) 지역번호 se1.kr 로 붙는 사용자 아이디의 사용자는 중계서버#1(relay server#1)(400)만 사용하며, (3) 사용자의 최초 등록 시, 사용자가 se1.kr 의 지역번호를 선택하면 지역번호 se1.kr에 해당하는 중계서버(400) 내에서만 사용자 아이디 내에 들어가는 사용자 이메일 주소의 중복 검사를 실행하면 중계서버 전체에서 해당 사용자 아이디의 유일성을 검증할 수 있게 된다. 왜냐면, 한 지역번호 내에서, 즉 해당 지역번호의 중계서버 내에서, 해당 사용자의 이메일 주소만 유일성이 검증되면, 해당 사용자 이메일 주소 및 지역번호의 조합에 해당되는 사용자 아이디는 중계서버들 전체에서 유일성이 보장되기 때문이다. (4) se2.kr 이 붙은 사용자 아이디의 등록 데이터나 인증정보가 중계서버#3(relay server#3)(400)으로 전송되면 중계서버에서 해당 프로세스를 중단한다. 즉, 중계서버에서 자신이 사용자단말기로부터 받은 등록데이터나 인증정보 내의 사용자 아이디안의 지역번호가 자신의 지역번호와 맞지 않으면 해당 프로세스를 중단한다. 그리고, 포털서버가 중계서버로 보낸 성공신호 내의 사용자 아이디 내의 지역번호가 중계서버 자신의 지역번호와 맞지 않아도 해당 프로세스를 중단한다. (5) 사용자가 최초 등록 시, 관리자가 해당 사용자의 중계서버#n(relay server#n)(400)의 DB에 해당 사용자의 이메일 주소를 임시 저장하여, 사용자가 해당 중계서버에서 상기 이메일 주소만 등록 가능하도록 제약할 수도 있다. (6) 사용자가 사용자 최초 등록 시에 중계서버를 선택해서 지역번호를 선택하면, 해당 중계서버에 연결된 사용자단말기기가 해당 중계서버에서 해당 사용자 이메일 주소의 유일성을 검증 후에 자동으로 사용자 아이디, 즉 사용자 이메일 주소+지역번호를 만들고 해당 사용자 아이디를 사용자단말기 안에 저장한다. 이후, 해당 중계서버에 연결된 사용자단말기가 개인키, 공개키, 및 등록데이터 등을 추가로 만들어서 사용자단말기 안에 해당 개인키, 공개키 및 등록데이터 등을 각각 다 저장하고 이들을 계속 사용한다. 이때 개인키 안에 사용자 아이디, 사용자가 개인키에 접근할 때 필요한 비밀번호, 그리고 중계서버에 접근하기 위한 중계서버 URL 들을 삽입해서 쓰는데, 이후에 상기 개인키를 쓸 때에는 상기 개인키에 삽입한 내용들을 해당 개인키에서 빼서 원래의 개인키 원본을 만든 후에 해당 개인키를 사용한다. 그리고, 사용자가 등록, 인증, 탈퇴 시 마다 자신의 사용자단말기안의 개인키에 접근해야 하는데, 이때 사용자의 등록, 인증, 탈퇴 시 마다 사용자가 화면상에서 입력한 비밀번호가 개인키안에 삽입된 비밀번호와 일치하지 않으면 개인키에 대한 접근을 허가하지 않고 바로 프로세스를 중단한다. 이 들어있다. 그리고, 공개키 안에 사용자 아이디와 중계서버에 접근하기 위한 중계서버 URL 주소 들을 삽입해서 쓰는데, 이후에 상기 공개키를 쓸 때에는 상기 공개키에 삽입한 내용들을 해당 공개키에서 빼서 원래의 공개키 원본을 만든 후에 해당 공개키를 사용한다. 이때, 공개키 안에 삽입된 중계서버 URL 정보는 향후 사용자단말기기가 사용자 자신의 등록데이터나 인증정보를 중계서버로 보내기 위해서 사용되고 포털서버가 성공신호를 중계서버로 보내기 위해서 사용된다. 가 들어있다. 마지막으로, 등록데이터의 경우, 사용자 아이디, 사용자 아이디의 공개키와 이 사용자 아이디와 해당 사용자 아이디의 공개키를 해당 사용자의 개인키로 전자서명한 값이 들어있다. (7) 상기 사용자 아이디 지역번호 아키텍쳐를 사용하면, 여러 중계서버(400)들 중에 사용자는 1개의 중계서버(400)만 고정적으로 사용하게 되어, 전체 시스템의 중계서버(400)들을 다 조사하지 않아도 1개 중계서버(400)만을 조사해서 사용자의 단일계정 여부, 중계서버(400) 우회 등록, 우회 인증, 우회 탈퇴에 대한 대응 및 이메일 대응, 해커의 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴 하려는 시도 대응 및 이메일 대응, 그리고 개인키 유출 사고 대응 및 이메일 대응을 훨씬 효율적으로 빠른 시간 내에 할 수 있게 되는 것이다.

도 1과 도 3에 도시한 바와 같이, 개인키 유출사고 대응 시나리오를 살펴보면, (1) 중계서버(400)를 사용해서 다른 사람의 사용자 아이디와 해당 사용자의 해킹된 개인키로 만든 공개키를 등록하거나 해당 개인키로 만든 공개키로 인증 및 탈퇴를 하려는 시도 시, 중계서버(400) 내에서 최초 사용자 등록 시 이미 저장된 해당 사용자의 사용자 아이디, 공개키, 이들의 사용자 전자서명 값인 등록데이터를 개인키 유출된 데이터로 마킹한다. 이후, shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 성공신호와 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 중계서버(400)에 미리 임시 저장된 인증신호와 사용자 아이디, 공개키, 이들의 사용자 전자서명 값 등의 중계서버(400)에 미리 임시 저장된 등록데이터를 중계서버(400)에서 서로 비교해서 사용자 아이디를 기준으로 공개키 등이 서로 일치하고, 상기 임시 저장된 등록데이터에 해당되는 중계서버(400)에 사용자 최초 등록 시 미리 저장된 등록데이터가 개인키 유출로 마킹되어 있으면, 이를 개인키 유출 사고로 본다. 이후, 중계서버(400)에서 해당 포털서버(300)로 상기 성공신호의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 및 https를 활용해서 전송한다. 하지만, 중계서버(400)에서 사용자 자신이나 해커의 개인키 유출 사고의 탈퇴의 경우에는, 보조인증을 성공으로 보고, 상기 성공신호 내의 난수정보가 포함된 성공 메시지와 사용자 아이디를 중계서버(400)에서 포털서버(300)로 VPN 이나 https를 활용해서 보낸다. 이후, 포털서버(300)에서 중계서버(400)로부터 상기 실패메시지와 사용자 아이디를 받은 경우, 사용자단말기(200)가 포털서버(300)로 shuffle 번호대로 shuffle 해서 보내고, 포털서버(300)에서 shuffle 번호대로 복원에 성공해서 중간자 공격이 없음을 확인하고 전자서명 검증이 된, 즉, 복원된 인증정보 내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본을 해쉬한 것들이 원본의 해쉬들하고 하나라도 불일치되는 경우가 없고 전자서명 검증이된 인증정보의 고객사 웹 서버(100) URL이 해킹을 당했다고 보고 포털서버(300)에서 해당 사용자에게 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 사고내용, 즉, 개인키 유출 사고 시 해커의 등록, 인증 시도를 전송한다. 이후, 포털서버(300)에서 중계서버(400)로부터 상기 실패메시지와 사용자 아이디를 받으면, 해당 포털서버(300)에서 해당 등록 및 인증을 최종적으로 취소한다. 하지만, 포털서버(300)가 중계서버(400)로부터 성공 메시지와 사용자 아이디를 받은 개인키 유출 사고의 사용자 자신 또는 해커의 탈퇴의 경우 사용자단말기(200)가 포털서버(300)로 shuffle 번호대로 shuffle 해서 보내고, 포털서버(300)에서 shuffle 번호대로 복원에 성공해서 중간자 공격이 없음을 확인하고 전자서명 검증이 된, 즉, 복원된 인증정보 내의 원본과 원본의 해쉬들에서 원본을 해쉬했을 때 원본을 해쉬한 것들이 원본의 해쉬들하고 하나라도 불일치되는 경우가 없고 전자서명 검증이된 인증정보의 고객사 웹 서버(100) URL이 해킹을 당했다고 보고 포털서버(300)에서 해당 사용자에게 사용자 아이디 내의 이메일 주소를 활용해서 이메일로 사고내용, 즉, 개인키 유출 사고 시 해커 및 사용자 자신의 탈퇴 시도를 전송한다. 이후, 포털서버에서 해당 탈퇴를 포털서버(300)에서 최종적으로 진행한다. 이는 도 1에 도시한 바와 같은, 1번부터 12번까지가 하나의 프로세스이기 때문에 가능하다. 하지만, 해당 사용자의 등록, 인증, 탈퇴의 경우, 상기 성공신호 전에 사용자단말기(200)에서 중계서버(400)로 보낸 등록데이터가 사용자의 최초 등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 일치 시, 또는 사용자단말기(200)에서 중계서버(400)로 보낸 인증정보의 사용자 아이디와 공개키가 상기 미리 임시 저장된 등록데이터와 일치하고 이 임시 저장된 등록데이터가 사용자의 최초등록 시에 미리 저장되고 개인키 유출로 마킹된 등록데이터와 사용자 아이디를 기준으로 서로 일치 시, 개인키 유출 사고로 본다. 이때, 개인키 유출 사고의 등록, 인증의 경우엔 등록데이터끼리 일치하는 전자의 경우엔 프로세스를 중단하고, 미리 저장되었거나 임시 저장된 등록데이터들과 인증정보의 사용자 아이디와 공개키가 서로 일치하는 후자의 경우엔 중계서버가 사용자단말기로부터 받은 인증정보를 활용해서 사용자에게 개인키 유출 사고를 상기 인증정보 내의 사용자 아이디 내의 이메일 주소를 활용해서 중계서버에서 보내고, 중계서버에서 해당 프로세스를 중단한다. 반면에, 개인키 유출 사고의 탈퇴의 경우엔, 중계서버에서 아무런 이메일 대응없이 해당 프로세스를 진행한다.

(2) 도 1과 도 4에 도시한 바와 같이, 해커의 다른 사용자의 다른 공개키 등록, 인증, 탈퇴 해킹 탐지를 살펴보면, 중계서버(400)를 사용해서 해커가 다른 사람의 사용자 아이디로 다른 공개키를 등록하거나 인증, 탈퇴 시 사용하려는 해킹 시, shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 성공신호를 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 중계서버(400)에 미리 임시 저장한 인증정보와 사용자 아이디, 공개키, 이들의 사용자 전자서명 값이고 중계서버(400)에 미리 임시 저장된 등록데이터와 중계서버(400)에서 비교해서 사용자 아이디별 공개키들이 서로 불일치 시, 중계서버(400)에서 해당 포털서버(300)로 상기 성공신호의 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전달한다. 이후, 사용자단말기(200)가 포털서버(300)로 shuffle 번호대로 shuffle 해서 보내고, 포털서버(300)에서 shuffle 번호대로 복원에 성공해서 중간자 공격이 없는 것이 검증되고 전자서명이 검증된, 즉 복원된 인증정보 내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본들을 해쉬한 것들이 원본의 해쉬들하고 각각 서로 비교해서 하나라도 불일치하는 것이 없고 전자서명 검증이 된 인증정보의 고객사 웹 서버(100) URL이 해킹을 당했다고 보고 해당 사용자에게 사용자 아이디 내에 있는 이메일 주소를 활용해서 포털서버(300)에서 이메일로 사고내용, 즉, 해커가 다른 사용자 아이디의 다른 공개키를 등록, 인증, 탈퇴 하려는 시도를 전송한다. 이후, 해당 포털서버(300)에서 최종적으로 등록, 인증, 탈퇴를 취소한다. 이는 도 1에 도시한 바와 같은, 1번부터 12번까지가 하나의 프로세스이기 때문에 가능하다. 또한, 상기 성공신호 전에 사용자단말기(200)가 중계서버(400)로 보낸 등록데이터가 사용자의 최초등록 시에 중계서버에 미리 저장된 등록데이터와 사용자 아이디별 공개키 등이 서로 불일치 시, 또는 사용자단말기(200)가 중계서버(400)에 보낸 인증정보와 중계서버에 미리 임시 저장된 등록데이터의 사용자 아이디별 공개키들이 서로 불일치 시, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹 사고로 보고 해당 등록, 인증, 탈퇴에 있어서 등록데이터끼리 불일치하는 전자의 경우엔 해당 프로세스를 중단하고, 등록데이터와 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 후자의 경우엔 중계서버(400)에서 사용자단말기(200)로부터 받은 인증정보를 가지고 해당 고객사 웹 서버(100) URL에서 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버(400)에서 상기 인증정보 내의 사용자 아이디 내의 사용자 이메일 주소를 활용해서 이메일로 해당 사고내용을 해킹 보고하고 해당 프로세스를 중단함으로서 미리 탐지가 또한 가능하다.

(3) 도 3과 도 4에서 도시한 바와 같이, 해커가 중계서버를 사용하지 않고 포털서버와 직접적으로 등록, 인증, 탈퇴하려는 시도, 즉 해커의 중계서버 우회 등록, 우회 인증, 우회 탈퇴의 시도 시, 즉, 포털서버가 중계서버에게 보내고 shuffle 번호에 따라 복원된 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 전자서명값의 해쉬 값 등의 성공신호에 해당되는 사용자단말기기가 중계서버로 보내고 shuffle 번호에 따라 복원된 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 중계서버에 미리 임시 저장된 인증정보가 중계서버에 없을 시, 해커의 중계서버를 우회해서 등록, 인증, 탈퇴하려는 시도로 보고, 중계서버에서 포털서버로 상기 성공신호에 해당되는 난수정보가 포함된 실패메시지와 사용자 아이디를 VPN 이나 https를 활용해서 전송한다. 이후, 포털서버에서 중계서버로부터 상기 실패 메지지와 사용자 아이디를 받으면, 사용자단말기에서 포털서버로 전송한 후에 shuffle 번호대로 복원되고 전자서명검증도 된, shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 값 등의 인증정보 중에서 고객사 웹 서버 URL이 해킹을 당했다고 보고 포털서버에서 사용자 아이디 내의 사용자 이메일 주소를 활용해서 해당 사고내용, 즉 해커가 중계서버를 우회해서 등록, 인증, 탈퇴를 하려는 중계서버 우회 등록, 우회 인증, 우회 탈퇴의 시도를 포털서버에서 이메일로 전송한다. 이후, 포털서버에서 해당 등록, 인증, 탈퇴를 최종적으로 취소하는 것을 포함함을 특징으로 한다.

본 기술에서, 사용자단말기(200)가 중계서버(400)로 보내는 인증정보, 이 인증정보와 똑같은 사용자단말기(200)가 포털서버(300)로 보내는 인증정보, 그리고, 이 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔서 포털서버(300)에서 중계서버(400)로 주는 성공신호 등의 데이터들이 있다. 이 데이터들은 각각의 네트워크 구간에서 보내는 쪽에서 shuffle 번호대로 shuffle 하고(즉, 데이터를 shuffle 번호대로 자르고 섞는다) 받는 쪽에서 shuffle 번호대로 복원해서 제대로 복원되었는지를 검사하는 프로세스를 가지고 있다. 즉, 보내는 쪽에선 shuffle 번호대로 이 데이터들을 shuffle 하고, 받는 쪽에선 shuffle 번호대로 복원한 후에, 복원된 데이터 내의 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본을 해쉬한 것들이 원본의 해쉬들하고 하나라도 불일치되는 경우가 있는지 없는 지를 검사한다. 이때, 원본을 해쉬한 것들과 원본의 해쉬들이 하나라도 불일치하면 해커의 중간자 공격으로 정의하게 된다. 본 기술에서 이 shuffle를 하는 이유는 https 와 같은 TLS 암호화 통신을 사용하지 않는 경우에 해커의 중간자 공격을 방어하기 위해서이다. 즉, 암호화 통신을 사용하지 않으면, shuffle 기능 때문에 해커는 shuffle 된 데이터를 원복할 수 없어 임의로 shuffle 된 데이터를 변경할 수 밖에 없게 되고 이렇게 되면, shuffle 된 데이터를 원복하고 나서 원본과 원본의 해쉬들에서 원본들을 해쉬했을 때 원본을 해쉬한 것들이 원본의 해쉬들하고 하나라도 불일치되는 경우가 발생할 수밖에 없어서 중간자 공격을 탐지할 수 있게 된다. 하지만, 네트워크 구간에서 https 통신과 같은 TLS 암호화 통신을 할 때에는 이 shuffle 기능이 굳이 필요 없게 된다. 왜냐하면, https 와 같은 TLS 통신의 경우, 해커는 암호화된 상기 데이터들을 복호화할 수 없어 해커는 해당 데이터들을 임의로 변경할 수밖에 없게 되고, 이렇게, 암호화된 상기 데이터가 해커에 의해서 임의로 변경이 되면, 받는 쪽에서 해당 데이터를 복호화했을 때 원본과 원본의 해쉬들로 구성된 상기 데이터는 원본을 해쉬한 것들과 원본의 해쉬들이 서로 일치하지 않게 되어 해커의 중간자 공격이 탐지될 수 있기 때문이다. 즉, 원본이 변경되면 해당 원본을 해쉬한 것과 원본의 해쉬값이 틀려지게 되고, 원본의 해쉬가 변경이 되면 원본을 해쉬한 것과 변경된 원본의 해쉬가 틀려지게 된다. 그리고, 원본과 원본의 해쉬가 동시에 변경이 되면 해쉬 알고리즘의 특성상 변경된 해당 원본을 해쉬한 것과 변경된 해당 원본의 해쉬가 틀려지게 될 확률이 아주 높아지게 된다. 따라서, 해커의 중간자 공격을 탐지하기 위해서 https 와 같은 TLS 암호화 통신이 없으면 shuffle 기능이 해커의 중간자 공격 탐지를 위해서 필요하겠지만, https 와 같은 TLS 암호화 통신에선 해커의 중간자 공격을 탐지하기 위해서 shuffle 기능까지는 필요 없게 된다. 따라서, 본 발명에서는 이 shuffle 기능을 필요할 때만 사용하는 옵션으로 정의하고자 한다. 따라서, shuffle 기능을 쓰지 않을 때에는 다음처럼 적용한다. shuffle 하기 위해서 정의한 인증정보 및 성공신호의 데이터 포맷인 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 데이터 포맷을 shuffle 기능을 쓰지 않는 옵션의 인증정보 및 성공신호에선 다음과 같이 정의한다. 다시 말해서, shuffle 기능이 없는 인증정보 및 성공신호의 데이터 포맷을 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값, 사용자 전자서명값 해쉬 등의 데이터로 정의한다. 이렇게 shuffle 기능이 없는 인증정보와 성공신호를 쓰면, 해당 인증정보와 성공신호는 명칭만 틀리고 데이터 및 데이터 포맷이 서로 똑같게 된다. 그리고, shuffle 기능이 없이 사용자단말기(200)에서 중계서버(400)로, 또는 사용자단말기(200)에서 포털서버(300)로 인증정보를 보낼 때, 또는 포털서버(300)에서 중계서버(400)로 해당 성공신호를 보낼 때, 상기 데이터 포맷인 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값, 사용자 전자서명값 해쉬를 https를 활용해서 보내는 쪽에서도 그대로 보내고 받는 쪽에서도 그대로 받는다. 즉, 보내는 쪽에서 shuffle을 하거나, 받는 쪽에서 shuffle을 원복하는 기능을 생략한다. 하지만, 받는 쪽에선 받은 이후에 원본과 원본의 해쉬값들에서 원본을 해쉬했을 때, 해쉬된 것들과 원본의 해쉬값들을 서로 비교해서 불일치하는 것이 하나라도 있는지 검사하고 하나라도 불일치하는 경우에 해당 프로세스를 중단하는 기능은 그대로 둔다. 이때 사용자단말기(200)에서 중계서버(400)로, 또는 사용자단말기(200)에서 포털서버(300)로 인증정보를 보낼 때, 또는 포털서버(300)에서 중계서버(400)로 해당 성공신호를 보낼 때, shuffle 기능을 사용할 경우엔 상기 인증정보 및 성공신호를 받는 쪽에서 shuffle 된 것을 원복한다. 이때, 원복된 인증정보 및 성공신호의 데이터 포맷이 shuffle 번호, shuffle 번호 해쉬, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버(100) URL, 고객사 웹 서버(100) URL 해쉬, 이들의 사용자 전자서명값(shuffle 번호, shuffle 번호 해쉬 제외), 사용자 전자서명값의 해쉬 등의 미리 정의된 데이터 포맷과 일치하는지 상기 중계서버나 포털서버에서 검증한다. 그리고, shuffle 기능을 사용하지 않으면 받는 쪽에선 상기 인증정보 및 성공신호를 그대로 받는다. 이때 shuffle 기능을 사용하지 않아서 받는 쪽에서 그대로 받은 인증정보나 성공신호의 데이터 포맷이, 사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 프로세스, 프로세스 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값, 사용자 전자서명값 해쉬 등의 미리 정의된 데이터 포맷과 일치한는지 상기 중계서버나 포털서버에서 검증한다. 이후, shuffle 기능을 사용하거나 shuffle 기능을 사용하지 않는 상기 두 경우 모두에 있어서, 상기 중계서버나 포털서버와 같이 인증정보나 성공신호를 받는 쪽에서 받은 인증정보나 성공신호의 데이터 포맷이 상기처럼 검증되어 받는 쪽에서 받은 인증정보나 성공신호의 데이터 포맷이 상기 미리 정의된 데이터 포맷과 서로 일치하면 등록, 인증, 탈퇴에 있어서 해당 프로세스를 해당 중계서버나 포털서버에서 그대로 진행하고, shuffle 기능을 사용하거나 shuffle 기능을 사용하지 않는 상기 두 경우 모두에 있어서, 상기 중계서버나 포털서버와 같이 인증정보나 성공신호를 받는 쪽에서 받은 인증정보나 성공신호의 데이터 포맷의 검증이 실패하여 받는 쪽에서 받은 인증정보나 성공신호의 데이터 포맷이 상기 미리 정의된 데이터 포맷과 서로 일치되지 않으면 등록, 인증, 탈퇴에 있어서 해당 프로세스를 해당 중계서버나 포털서버에서 중단한다. 즉, 인증정보를 사용자단말기가 중계서버나 포털서버로 보낼 때, 성공신호를 포털서버에서 중계서버로 보낼 때, 받는 쪽에서 해당 인증정보 및 성공신호의 데이터 포맷을 미리 정의된 데이터 포맷과 비교해서, 일치하면 등록, 인증, 탈퇴에 있어서 해당 프로세스를 해당 중계서버나 포털서버에서 그대로 진행하고, 일치하지 않으면 등록, 인증, 탈퇴에 있어서 해당 프로세스를 해당 중계서버나 포털서버에서 중지한다. 이때, shuffle 기능을 쓰면, 받는 쪽에서 shuffle 된 것을 원복한 후에 해당 원복된 인증정보나 성공신호의 데이터 포맷을 미리 정의된 데이터 포맷과 비교하고, shuffle 기능을 쓰지 않으면, 받는 쪽에서 변경시키지 않고 그대로 받은 인증정보나 성공신호를 미리 정의된 데이터 포맷과 비교한다. 여기서, 상기 데이터 포맷 비교 검증은 사용자단말기가 중계서버로 인증정보를 보내자마자 맨 처음, 사용자단말기가 포털서버로 인증정보를 보낸 경우엔 해당 인증정보를 포털서버에서 전자서명 검증하기 전에, 포털서버가 성공신호를 포털서버로부터 중계서버로 보낸 경우엔 해당 성공신호를 가지고 중계서버에서 보조인증을 하기 전에 실행하고, 이후, 다음단계 넘어가기 전에 등록, 인증, 탈퇴에 있어서 해당 프로세스를 데이터 포맷 비교 검증의 성공의 경우엔 그대로 진행하거나 데이터 포맷 비교 검증의 실패의 경우엔 즉시 중지한다.

이상에서 설명한 바와 같이, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경이 가능하므로 전술한 실시예 및 첨부된 도면에 한정되는 것은 아니다.

상술한 바와 같이, 본 발명인 포털사이트 중계 서비스 제공 시스템 및 그 방법은 포털사이트에서의 보안 분야에 폭 넓게 적용할 수 있는 것이다.

100 : 고객사 웹 서버
200 : 사용자단말기(또는 사용자단말기 클라이언트)
300 : 포털 서버(SIDSL 서비스 서버)
400 : 중계서버(relay server)

Claims

포털사이트 중계서버(이하 '중계서버'라 한다)의 중계 서비스 제공 방법으로서,
(a) 사용자단말기로부터 중계서버가 사용자 아이디, 공개키 및 이들의 전자서명 값이 포함된 등록 데이터를 포함하는 사용자 요청을 수신하는 단계;
(b) 상기 단계(a)의 사용자 요청이 사용자의 최초 등록 요청인 경우, 상기 사용자 아이디 내의 지역번호가 상기 중계서버와 맞지 않으면 프로세스를 중단하고 맞으면 다음 단계로 진행하는 단계;
(c) 상기 단계(a)의 사용자 요청이 사용자의 최초 등록 이후의 등록, 인증 또는 탈퇴 요청인 경우, 사용자의 최초 등록시 저장되었던 등록데이터와, 상기 단계(a)에서 수신한 등록데이터를 사용자 아이디를 기준으로 서로를 찾은 후에 서로 매칭되는 것이 없거나, 매칭되는 것이 있더라도, 최초 등록시 미리 저장된 등록데이터를 해쉬값으로 만들고, 사용자단말기가 새로 보낸 등록데이터도 해쉬값으로 만든 후, 서로의 해쉬값들을 비교하여 해쉬값들이 서로 불일치하는 경우 상기 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 상기 해쉬값들이 서로 일치하는 경우 다음 단계로 진행하되, 단, 관리자가 사용자의 신고로, 중계서버에 최종 등록 시 미리 저장된 사용자의 등록데이터를 개인키 유출 사고로 마킹한 경우, 마킹된 등록데이터의 해쉬값과 상기 단계(a)에서 사용자단말기로부터 수신한 등록데이터의 해쉬값이 서로 일치한다면, 상기 단계(a)의 사용자 요청이 개인키 유출 사고에 해당하는 사용자 요청으로 판단하고, 이때 상기 단계(a)의 사용자의 요청이 개인키 유출 사고의 등록, 인증인 경우에는 중계서버가 사용자단말기로 실패메시지를 전송 후 프로세스를 중단하고, 상기 단계(a)의 사용자의 요청이 개인키 유출 사고의 탈퇴인 경우에는 다음 단계로 진행하는 단계;
(d) 최초 등록인 경우 상기 등록데이터를 영구 저장하고, 최초 등록 이후의 등록, 인증 또는 탈퇴 요청인 경우, 상기 등록데이터를 임시 저장하는 단계;
(e) 상기 등록데이터를 포털사이트 서버(이하 '포털서버'라 한다)로 전송하는 단계;
(f) 상기 포털서버로부터 사용자 아이디, 난수 및 이들의 해쉬값을 수신하는 단계;
(g) 상기 포털서버로부터 수신한 사용자 아이디, 난수 및 이들의 해쉬값을 상기 사용자단말기로 전송하는 단계;
(h) 사용자단말기로부터 인증정보를 수신하는 단계;
(i) 상기 인증정보와, 중계서버에 미리 임시 저장된 등록데이터를 비교하여 사용자 아이디별 공개키가 서로 불일치하는 경우 상기 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 공개키가 사용자 아이디별로 서로 일치하는 경우 다음 단계로 진행하되, 단, 개인키 유출 사고의 경우 상기 인증정보와 중계서버에 미리 임시 저장된 등록데이터를 비교하여 공개키가 서로 일치하더라도, 개인키 유출 사고의 등록, 인증의 경우에는 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 개인키 유출 사고의 탈퇴의 경우에는 다음 단계로 그대로 진행하는 단계;
(j) 상기 인증정보를 임시저장하는 단계;
(k) 상기 포털서버로부터 상기 사용자 아이디에 해당하는 공개키 요청을 수신하는 단계;
(l) 상기 사용자 아이디에 해당하는 공개키를 상기 포털서버로 송신하는 단계;
(m) 상기 포털서버에서 인증정보 검증 성공된 경우, 상기 포털서버로부터 성공신호를 수신하는 단계;
(n) 상기 성공신호로부터 상기 사용자 요청에 대한 최종 검증을 수행하는 단계; 및,
(o) 상기 사용자 요청에 대한 최종 검증 결과가 성공인 경우 성공메시지를 상기 포털서버로 전송하고, 상기 사용자 요청에 대한 최종 검증 결과가 실패인 경우 실패메시지를 상기 포털서버로 전송하는 단계
를 포함하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 단계(a)에서 사용자단말기로부터 중계서버가 수신하는 데이터에는,
포털서버 URL 정보를 더 포함하고,
중계서버가 포털서버에 메시지 전송시에는,
상기 포털서버 URL 정보에 해당하는 포털서버에 전송하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 사용자 아이디는,
이메일 주소 및 지역번호를 포함하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 3에 있어서,
상기 지역번호는,
사용자 전용 중계서버를 의미하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 단계(b)와 단계(c) 사이에,
(b1) 상기 단계(a)의 사용자 요청이 사용자의 최초 등록 요청인 경우, 상기 사용자 아이디의 유일성을 검증하여, 유일성이 인정되지 않으면 프로세스를 중단하고, 유일성이 인정되면 다음 단계로 진행하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 단계(b)와 단계(c) 사이에,
(b2) 상기 단계(a)의 사용자 요청이 사용자의 최초 등록 요청인 경우, 상기 등록데이터의 전자서명을 검증하여, 검증 실패시 프로세스를 중단하고, 검증된 경우 상기 등록데이터를 저장한 후 다음 단계로 진행하는 단계
를 더 포함하는 것을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 단계(c)에서,
사용자의 최초 등록시 저장되었던 등록데이터와, 상기 단계(a)에서 수신한 등록데이터 일치 여부 판단은,
사용자의 최초 등록 시 미리 저장된 등록데이터와 상기 단계(a)에서 수신한 등록데이터를 사용자 아이디를 기준으로 매칭시켜 서로를 찾은 후에 서로 매칭되는 것이 없거나, 또는 매칭이 되더라도 서로를 해쉬값으로 비교한 후 불일치한 경우에 불일치하는 것으로 판단하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 인증정보에는,
사용자 아이디, 사용자 아이디 해쉬, 공개키, 공개키 해쉬, 난수, 난수 해쉬, 포털서버 URL, 포털서버 URL 해쉬, 고객사 웹 서버 URL, 고객사 웹 서버 URL 해쉬, 이들의 사용자 전자서명값, 사용자 전자서명값의 해쉬를 포함하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 8에 있어서,
상기 사용자단말기와 상기 중계서버 간의 네트워크 구간에서 암호화 통신을 사용하는 경우, 상기 단계(h)의 인증정보는 셔플링(shuffling) 되지 않은 상태로 수신되고, 이 경우 상기 단계(h)와 단계(i) 사이에,
(h1) 상기 인증정보의 원본을 해쉬한 것들과 원본의 해쉬값들을 비교하여　상기 네트워크 구간에서 해커가 상기 인증정보의 데이터 변경을 했는지의 여부를 검증하여 데이터 변경이 행해진 경우 프로세스를 중단하고, 데이터 변경이 행해지지 않은 경우 다음 단계로 진행하는 것
을 더 포함하고,
상기 사용자단말기와 상기 중계서버 간의 네트워크 구간에서 암호화 통신을 사용하지 않는 경우, 상기 단계(h)의 인증정보는 셔플링(shuffling)된 상태로 수신되고, 상기 인증정보에는 shuffle 번호, shuffle 번호 해쉬를 더 포함하며, 이 경우 상기 단계(h)와 단계(i) 사이에,
(h2) 상기 인증정보에 포함된 데이터를 shuffle 번호대로 복원하고, 복원된 인증정보 내의 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들을 비교하여, 서로 하나라도 불일치하는 경우, 복원 실패로 판단하여 프로세스를 중단하고, 모두 일치하는 경우 복원 성공으로 판단하여 다음 단계로 진행하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 9에 있어서,
상기 단계(h1)와 단계(i) 사이 또는 상기 단계(h2)와 단계(i) 사이에,
(h3) 상기 인증정보의 전자서명을 검증하여, 검증 실패 시 해당 프로세스를 중단하고, 검증 성공시 다음 단계로 진행하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 8에 있어서,
상기 단계(i)에서, 상기 인증정보와, 중계서버에 저장된 등록데이터의 일치 여부는,
아이디별 공개키들이 서로 일치하는지 여부로 판단하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 단계(l)의 공개키는,
상기 사용자 아이디에 해당하는 등록데이터에 포함된 공개키인 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 사용자단말기와 상기 중계서버 간의 네트워크 구간에서 암호화 통신을 사용하는 경우, 상기 단계(m)의 성공신호는 셔플링(shuffling) 되지 않은 상태로 수신되고, 이 경우 상기 단계(m)과 단계(n) 사이에,
(m1) 상기 성공신호의 원본을 해쉬한 것들과 원본의 해쉬값들을 비교하여　상기 네트워크 구간에서 해커가 상기 성공신호의 데이터 변경을 했는지의 여부를 검증하여 데이터 변경이 행해진 경우 프로세스를 중단하고, 데이터 변경이 행해지지 않은 경우 다음 단계로 진행하는 것
을 더 포함하고,
상기 사용자단말기와 상기 중계서버 간의 네트워크 구간에서 암호화 통신을 사용하지 않는 경우, 상기 단계(k)의 성공신호는 셔플링(shuffling)된 상태로 수신되고, 이 경우 상기 단계(m)와 단계(n) 사이에,
(m2) 상기 성공신호에 포함된 데이터를 shuffle 번호대로 복원하고, 복원된 성공신호 내의 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들을 비교하여, 서로 하나라도 불일치하는 경우, 복원 실패로 판단하여 프로세스를 중단하고, 모두 일치하는 경우 복원 성공으로 판단하여 다음 단계로 진행하는 것
을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 단계(n)의 최종 검증은,
(n1) 상기 성공신호에 해당되는, 사용자단말기로부터 수신되어 임시저장된 인증정보가 없는 경우, 해커의 우회 등록, 우회 인증 및 우회 탈퇴 시도 중 어느 하나로 인정하여 상기 사용자 요청에 대한 최종 검증 결과를 실패로 판단하는 단계
를 포함하는 것을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 단계(n)의 최종 검증은,
(n21) 상기 성공신호에 해당되는, 사용자단말기로부터 수신되어 임시저장된 인증정보가 있는 경우, 상기 성공신호와, 이에 해당하는 임시저장된 상기 인증정보의 사용자 아이디별 공개키들의 일치여부를 파악하는 단계;
(n22) 상기 성공신호와, 이에 해당하는 임시저장된 상기 인증정보의 사용자 아이디별 공개키들이 서로 불일치하는 경우, 다른 사용자 아이디로 다른 공개키를 등록, 인증, 탈퇴하려는 해킹시도로 보아, 상기 사용자 요청에 대한 최종 검증 결과를 실패로 판단하는 단계
를 더 포함하는 것을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
청구항 1에 있어서,
상기 단계(n)의 최종 검증은,
(n31) 상기 성공신호와, 이에 해당하는 임시저장된 상기 인증정보를 서로 비교해서 shuffle 번호와 shuffle 번호 해쉬를 제외하고 서로 일치하는 경우, 사용자 아이디를 기준으로 상기 성공신호에 해당되고 사용자가 최초 등록 시에 미리 저장한 등록데이터가 개인키 유출로 마킹된 것인지 여부를 판단하는 단계;
(n32) 개인키 유출로 마킹된 것이 아닌 경우, 상기 사용자 요청에 대한 최종 검증 결과를 성공으로 판단하는 단계;
(n33) 개인키 유출로 마킹된 것인 경우, 상기 사용자 요청이 등록 또는 인증인 경우에는 상기 사용자 요청에 대한 최종 검증 결과를 실패로 판단하고, 상기 사용자 요청이 탈퇴인 경우에는 상기 사용자 요청에 대한 최종 검증 결과를 성공으로 판단하는 단계
를 더 포함하는 것을 특징으로 하는 포털사이트 중계서버의 중계 서비스 제공 방법.
포털사이트 중계서버(이하 '중계서버'라 한다)와 연계한 포털사이트 서버(이하 '포털서버'라 한다)의 포털 서비스 제공 방법으로서,
(a) 포털서버가 중계서버로부터, 등록, 인증 및 탈퇴 요청중 어느 하나에 해당하는 사용자 요청에 따른 등록데이터를 수신하는 단계;
(b) 상기 중계서버로, 사용자 아이디, 난수 및 이들의 해쉬값을 전송하는 단계;
(c) 사용자단말기로부터 상기 사용자 요청에 따른 인증정보를 수신하는 단계;
(d) 상기 사용자 아이디에 해당하는 공개키 요청을 상기 중계서버로 송신하는 단계;
(e) 상기 중계서버로부터, 상기 사용자 아이디에 해당하는 공개키를 수신하는 단계;
(f) 상기 인증정보에 대해서 상기 단계(e)에서 수신한 공개키를 이용하여 전자서명 검증을 하여, 검증 실패인 경우 단계(i)로 진행하고, 검증 성공인 경우 단계(g)로 진행하는 단계;
(g) 상기 인증정보 내의 사용자 아이디와 난수 데이터들을, 상기 포털서버 자신이 상기 중계서버를 통해 사용자단말기로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당되는 데이터와, 사용자 아이디를 기준으로 매칭시키는 단계;
(h) 상기 단계(g)에서 매칭시킨 해당 난수들이 서로 일치하지 않는 경우 검증 실패로 판단하고, 모두 일치하는 경우 검증 성공으로 판단하는 단계;
(i) 상기 단계(f)에서 전자서명 검증 실패이거나 상기 단계(h)에서 검증 실패인 경우, 해당 등록, 인증, 탈퇴 요청을 실패처리하고 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후 상기 실패메시지와 사용자 아이디를 사용자단말기로 전송하고, 또는 상기 단계(f)에서 전자서명 검증 성공이고 상기 단계(h)에서 검증 성공인 경우 성공신호를 중계서버로 전송하는 단계; 및,
(j) 상기 단계(i)에서 성공신호를 중계서버로 전송한 후에, 상기 중계서버로부터 성공메시지를 수신한 경우 최종적으로 성공처리하고, 상기 중계서버로부터 실패메시지를 수신한 경우 최종적으로 실패처리하는 단계
를 포함하는 중계서버와 연계한 포털서버의 포털 서비스 제공 방법.
청구항 17에 있어서,
상기 사용자단말기와 상기 포털서버 간의 네트워크 구간에서 암호화 통신을 사용하는 경우, 상기 단계(c)의 인증정보는 셔플링(shuffling) 되지 않은 상태로 수신되고, 상기 인증정보에는 shuffle 번호, shuffle 번호 해쉬를 더 포함하며, 이 경우 상기 단계(c)와 단계(d) 사이에,
(c1) 상기 인증정보의 원본을 해쉬한 것들과 원본의 해쉬값들을 비교하여　상기 네트워크 구간에서 해커가 상기 인증정보의 데이터 변경을 했는지의 여부를 검증하여 데이터 변경이 행해진 경우 프로세스를 중단하고, 데이터 변경이 행해지지 않은 경우 다음 단계로 진행하는 것
을 더 포함하고,
상기 사용자단말기와 상기 포털서버 간의 네트워크 구간에서 암호화 통신을 사용하지 않는 경우, 상기 단계(c)의 인증정보는 셔플링(shuffling)된 상태로 수신되고, 이 경우 상기 단계(c)와 단계(d) 사이에,
(c2) 상기 인증정보에 포함된 데이터를 shuffle 번호대로 복원하고, 복원된 인증정보 내의 원본과 원본의 해쉬들에서 원본을 해쉬한 것들과 원본의 해쉬들을 비교하여, 서로 하나라도 불일치하는 경우, 복원 실패로 판단하여 프로세스를 중단하고, 모두 일치하는 경우 복원 성공으로 판단하여 다음 단계로 진행하는 것
을 특징으로 하는 중계서버와 연계한 포털서버의 포털 서비스 제공 방법.
청구항 17에 있어서,
상기 단계(h)에서,
상기 포털서버와 상기 중계서버 간의 네트워크 구간에서 암호화 통신을 사용하지 않는 경우, 상기 단계(h)의 성공신호는,
사용자단말기로부터 받은 상기 인증정보에서 shuffle 번호와 shuffle 번호 해쉬만 바꿔 만들어지며, 상기 포털서버는, 이 성공신호를 shuffle 번호대로 셔플링 한 후 중계서버로 전송하고,
상기 포털서버와 상기 중계서버 간의 네트워크 구간에서 암호화 통신을 사용하는 경우, 상기 단계(h)의 성공신호는,
셔플링을 하지 않고 그대로 중계서버로 전송하는 것
을 특징으로 하는 중계서버와 연계한 포털서버의 포털 서비스 제공 방법.
청구항 17에 있어서,
상기 단계(j)에서 성공메시지를 수신한 경우,
상기 단계(j) 이후,
(j1) time limit 이 있는 성공 토큰을 생성해서 이를 사용자 아이디와 함께 포털서버에 임시 저장하고, 이 time limit이 있는 성공 토큰과 사용자 아이디를 사용자단말기로 전송하는 단계
를 더 포함하는 것을 특징으로 하는 중계서버와 연계한 포털서버의 포털 서비스 제공 방법.
청구항 20에 있어서,
상기 단계(j)에서 성공메시지를 수신한 경우, 상기 사용자 요청이 탈퇴 요청으로서, 개인키 유출 사고로서 성공처리하는 경우, 최종적으로 성공처리하기 전에,
(j2) 사용자단말기로부터 수신하여 전자서명 검증된 인증정보 내의 해당 고객사 웹 서버 URL에서 사용자나 해커가 개인키 유출 사고의 탈퇴를 하는 것으로 보고 인증정보 내의 사용자 아이디 내의 사용자의 이메일 주소를 활용해서 해당 사용자에게 사고 내용을 전송하는 단계
를 더 포함하는 것을 특징으로 하는 중계서버와 연계한 포털서버의 포털 서비스 제공 방법.
청구항 17에 있어서,
상기 단계(j)에서 실패메시지를 수신한 경우,
상기 단계(j) 이후,
(j3) 사용자 아이디와 상기 실패메시지를 임시 저장하고, 상기 실패 메시지와 사용자 아이디를 각각 사용자단말기로 전송하는 단계
를 더 포함하는 것을 특징으로 하는 중계서버와 연계한 포털서버의 포털 서비스 제공 방법.
청구항 22에 있어서,
상기 단계(j)에서 실패메시지를 수신한 경우는,
개인키 유출 사고의 등록, 또는 인증의 경우이거나, 해커가 다른 사용자 아이디로 다른 공개키를 등록, 인증 또는 탈퇴하려는 경우이거나, 또는, 해커가 중계서버를 우회해서 등록, 인증 또는 탈퇴하려는 경우이고,
이로 인하여 상기 단계(j)에서 실패메시지를 수신한 경우,
사용자단말기로부터 받은 인증정보 내의 고객사 웹 서버 URL 주소가 해커에 의해서 해킹당하였음을 알리는 내용을 포함하여 이메일로 해당 사고 내용을 사용자에게 전송하고, 최종 실패 처리하는 것
을 특징으로 하는 중계서버와 연계한 포털서버의 포털 서비스 제공 방법.
청구항 20에 있어서,
상기 단계(j1) 이후,
(j41) 상기 성공 토큰 및 사용자 아이디를 임시 저장한 경우, 상기 임시 저장된 성공 토큰 및 사용자 아이디를 삭제하는 단계
를 더 포함하는 것을 특징으로 하는 중계서버와 연계한 포털서버의 포털 서비스 제공 방법.
청구항 22에 있어서,
상기 단계(j3) 이후,
(j42) 상기 실패메시지 및 사용자 아이디를 임시 저장한 경우, 상기 임시 저장된 실패메시지 및 사용자 아이디를 삭제하는 단계
를 더 포함하는 것을 특징으로 하는 중계서버와 연계한 포털서버의 포털 서비스 제공 방법.
포털사이트 중계 서비스를 제공하는 장치(이하 '중계서버'라 한다)로서,
적어도 하나의 프로세서; 및
컴퓨터로 실행가능한 명령을 저장하는 적어도 하나의 메모리를 포함하되,
상기 적어도 하나의 메모리에 저장된 상기 컴퓨터로 실행가능한 명령은, 상기 적어도 하나의 프로세서에 의하여,
(a) 사용자단말기로부터 중계서버가 사용자 아이디, 공개키 및 이들의 전자서명 값이 포함된 등록 데이터를 포함하는 사용자 요청을 수신하는 단계;
(b) 상기 단계(a)의 사용자 요청이 사용자의 최초 등록 요청인 경우, 상기 사용자 아이디 내의 지역번호가 상기 중계서버와 맞지 않으면 프로세스를 중단하고 맞으면 다음 단계로 진행하는 단계;
(c) 상기 단계(a)의 사용자 요청이 사용자의 최초 등록 이후의 등록, 인증 또는 탈퇴 요청인 경우, 사용자의 최초 등록시 저장되었던 등록데이터와, 상기 단계(a)에서 수신한 등록데이터를 사용자 아이디를 기준으로 서로를 찾은 후에 서로 매칭되는 것이 없거나, 매칭되는 것이 있더라도, 최초 등록시 미리 저장된 등록데이터를 해쉬값으로 만들고, 사용자단말기가 새로 보낸 등록데이터도 해쉬값으로 만든 후, 서로의 해쉬값들을 비교하여 해쉬값들이 서로 불일치하는 경우 상기 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 상기 해쉬값들이 서로 일치하는 경우 다음 단계로 진행하되, 단, 관리자가 사용자의 신고로, 중계서버에 최종 등록 시 미리 저장된 사용자의 등록데이터를 개인키 유출 사고로 마킹한 경우, 마킹된 등록데이터의 해쉬값과 상기 단계(a)에서 사용자단말기로부터 수신한 등록데이터의 해쉬값이 서로 일치한다면, 상기 단계(a)의 사용자 요청이 개인키 유출 사고에 해당하는 사용자 요청으로 판단하고, 이때 상기 단계(a)의 사용자의 요청이 개인키 유출 사고의 등록, 인증인 경우에는 중계서버가 사용자단말기로 실패메시지를 전송 후 프로세스를 중단하고, 상기 단계(a)의 사용자의 요청이 개인키 유출 사고의 탈퇴인 경우에는 다음 단계로 진행하는 단계;
(d) 최초 등록인 경우 상기 등록데이터를 영구 저장하고, 최초 등록 이후의 등록, 인증 또는 탈퇴 요청인 경우, 상기 등록데이터를 임시 저장하는 단계;
(e) 상기 등록데이터를 포털사이트 서버(이하 '포털서버'라 한다)로 전송하는 단계;
(f) 상기 포털서버로부터 사용자 아이디, 난수 및 이들의 해쉬값을 수신하는 단계;
(g) 상기 포털서버로부터 수신한 사용자 아이디, 난수 및 이들의 해쉬값을 상기 사용자단말기로 전송하는 단계;
(h) 사용자단말기로부터 인증정보를 수신하는 단계;
(i) 상기 인증정보와, 중계서버에 미리 임시 저장된 등록데이터를 비교하여 사용자 아이디별 공개키가 서로 불일치하는 경우 상기 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 공개키가 사용자 아이디별로 서로 일치하는 경우 다음 단계로 진행하되, 단, 개인키 유출 사고의 경우 상기 인증정보와 중계서버에 미리 임시 저장된 등록데이터를 비교하여 공개키가 서로 일치하더라도, 개인키 유출 사고의 등록, 인증의 경우에는 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 개인키 유출 사고의 탈퇴의 경우에는 다음 단계로 그대로 진행하는 단계;
(j) 상기 인증정보를 임시저장하는 단계;
(k) 상기 포털서버로부터 상기 사용자 아이디에 해당하는 공개키 요청을 수신하는 단계;
(l) 상기 사용자 아이디에 해당하는 공개키를 상기 포털서버로 송신하는 단계;
(m) 상기 포털서버에서 인증정보 검증 성공된 경우, 상기 포털서버로부터 성공신호를 수신하는 단계;
(n) 상기 성공신호로부터 상기 사용자 요청에 대한 최종 검증을 수행하는 단계; 및,
(o) 상기 사용자 요청에 대한 최종 검증 결과가 성공인 경우 성공메시지를 상기 포털서버로 전송하고, 상기 사용자 요청에 대한 최종 검증 결과가 실패인 경우 실패메시지를 상기 포털서버로 전송하는 단계
가 실행되도록 하는,
중계서버.
포털사이트 중계 서비스를 제공하기 위한, 컴퓨터로 판독 가능한 비일시적 저장 매체에 저장된 컴퓨터 프로그램으로서,
비일시적 저장 매체에 저장되며, 프로세서에 의하여,
(a) 사용자단말기로부터 중계서버가 사용자 아이디, 공개키 및 이들의 전자서명 값이 포함된 등록 데이터를 포함하는 사용자 요청을 수신하는 단계;
(b) 상기 단계(a)의 사용자 요청이 사용자의 최초 등록 요청인 경우, 상기 사용자 아이디 내의 지역번호가 상기 중계서버와 맞지 않으면 프로세스를 중단하고 맞으면 다음 단계로 진행하는 단계;
(c) 상기 단계(a)의 사용자 요청이 사용자의 최초 등록 이후의 등록, 인증 또는 탈퇴 요청인 경우, 사용자의 최초 등록시 저장되었던 등록데이터와, 상기 단계(a)에서 수신한 등록데이터를 사용자 아이디를 기준으로 서로를 찾은 후에 서로 매칭되는 것이 없거나, 매칭되는 것이 있더라도, 최초 등록시 미리 저장된 등록데이터를 해쉬값으로 만들고, 사용자단말기가 새로 보낸 등록데이터도 해쉬값으로 만든 후, 서로의 해쉬값들을 비교하여 해쉬값들이 서로 불일치하는 경우 상기 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 상기 해쉬값들이 서로 일치하는 경우 다음 단계로 진행하되, 단, 관리자가 사용자의 신고로, 중계서버에 최종 등록 시 미리 저장된 사용자의 등록데이터를 개인키 유출 사고로 마킹한 경우, 마킹된 등록데이터의 해쉬값과 상기 단계(a)에서 사용자단말기로부터 수신한 등록데이터의 해쉬값이 서로 일치한다면, 상기 단계(a)의 사용자 요청이 개인키 유출 사고에 해당하는 사용자 요청으로 판단하고, 이때 상기 단계(a)의 사용자의 요청이 개인키 유출 사고의 등록, 인증인 경우에는 중계서버가 사용자단말기로 실패메시지를 전송 후 프로세스를 중단하고, 상기 단계(a)의 사용자의 요청이 개인키 유출 사고의 탈퇴인 경우에는 다음 단계로 진행하는 단계;
(d) 최초 등록인 경우 상기 등록데이터를 영구 저장하고, 최초 등록 이후의 등록, 인증 또는 탈퇴 요청인 경우, 상기 등록데이터를 임시 저장하는 단계;
(e) 상기 등록데이터를 포털사이트 서버(이하 '포털서버'라 한다)로 전송하는 단계;
(f) 상기 포털서버로부터 사용자 아이디, 난수 및 이들의 해쉬값을 수신하는 단계;
(g) 상기 포털서버로부터 수신한 사용자 아이디, 난수 및 이들의 해쉬값을 상기 사용자단말기로 전송하는 단계;
(h) 사용자단말기로부터 인증정보를 수신하는 단계;
(i) 상기 인증정보와, 중계서버에 미리 임시 저장된 등록데이터를 비교하여 사용자 아이디별 공개키가 서로 불일치하는 경우 상기 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 공개키가 사용자 아이디별로 서로 일치하는 경우 다음 단계로 진행하되, 단, 개인키 유출 사고의 경우 상기 인증정보와 중계서버에 미리 임시 저장된 등록데이터를 비교하여 공개키가 서로 일치하더라도, 개인키 유출 사고의 등록, 인증의 경우에는 사용자단말기로 실패메시지 전송 후 프로세스를 중단하고, 개인키 유출 사고의 탈퇴의 경우에는 다음 단계로 그대로 진행하는 단계;
(j) 상기 인증정보를 임시저장하는 단계;
(k) 상기 포털서버로부터 상기 사용자 아이디에 해당하는 공개키 요청을 수신하는 단계;
(l) 상기 사용자 아이디에 해당하는 공개키를 상기 포털서버로 송신하는 단계;
(m) 상기 포털서버에서 인증정보 검증 성공된 경우, 상기 포털서버로부터 성공신호를 수신하는 단계;
(n) 상기 성공신호로부터 상기 사용자 요청에 대한 최종 검증을 수행하는 단계; 및,
(o) 상기 사용자 요청에 대한 최종 검증 결과가 성공인 경우 성공메시지를 상기 포털서버로 전송하고, 상기 사용자 요청에 대한 최종 검증 결과가 실패인 경우 실패메시지를 상기 포털서버로 전송하는 단계
가 실행되도록 하는 명령을 포함하는,
포털사이트 중계 서비스를 제공하기 위한, 컴퓨터로 판독 가능한 비일시적 저장 매체에 저장된 컴퓨터 프로그램.
포털사이트 중계서버(이하 '중계서버'라 한다)와 연계하여 포털 서비스를 제공하는 장치(이하 '포털서버'라 한다)로서,
적어도 하나의 프로세서; 및
컴퓨터로 실행가능한 명령을 저장하는 적어도 하나의 메모리를 포함하되,
상기 적어도 하나의 메모리에 저장된 상기 컴퓨터로 실행가능한 명령은, 상기 적어도 하나의 프로세서에 의하여,
(a) 포털서버가 중계서버로부터, 등록, 인증 및 탈퇴 요청중 어느 하나에 해당하는 사용자 요청에 따른 등록데이터를 수신하는 단계;
(b) 상기 중계서버로, 사용자 아이디, 난수 및 이들의 해쉬값을 전송하는 단계;
(c) 사용자단말기로부터 상기 사용자 요청에 따른 인증정보를 수신하는 단계;
(d) 상기 사용자 아이디에 해당하는 공개키 요청을 상기 중계서버로 송신하는 단계;
(e) 상기 중계서버로부터, 상기 사용자 아이디에 해당하는 공개키를 수신하는 단계;
(f) 상기 인증정보에 대해서 상기 단계(e)에서 수신한 공개키를 이용하여 전자서명 검증을 하여, 검증 실패인 경우 단계(i)로 진행하고, 검증 성공인 경우 단계(g)로 진행하는 단계;
(g) 상기 인증정보 내의 사용자 아이디와 난수 데이터들을, 상기 포털서버 자신이 상기 중계서버를 통해 사용자단말기로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당되는 데이터와, 사용자 아이디를 기준으로 매칭시키는 단계;
(h) 상기 단계(g)에서 매칭시킨 해당 난수들이 서로 일치하지 않는 경우 검증 실패로 판단하고, 모두 일치하는 경우 검증 성공으로 판단하는 단계;
(i) 상기 단계(f)에서 전자서명 검증 실패이거나 상기 단계(h)에서 검증 실패인 경우, 해당 등록, 인증, 탈퇴 요청을 실패처리하고 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후 상기 실패메시지와 사용자 아이디를 사용자단말기로 전송하고, 또는 상기 단계(f)에서 전자서명 검증 성공이고 상기 단계(h)에서 검증 성공인 경우 성공신호를 중계서버로 전송하는 단계; 및,
(j) 상기 단계(i)에서 성공신호를 중계서버로 전송한 후에, 상기 중계서버로부터 성공메시지를 수신한 경우 최종적으로 성공처리하고, 상기 중계서버로부터 실패메시지를 수신한 경우 최종적으로 실패처리하는 단계
가 실행되도록 하는,
포털서버.
포털사이트 중계서버(이하 '중계서버'라 한다)와 연계하여 포털 서비스를 제공하기 위한, 컴퓨터로 판독 가능한 비일시적 저장 매체에 저장된 컴퓨터 프로그램으로서,
비일시적 저장 매체에 저장되며, 프로세서에 의하여,
(a) 포털서버가 중계서버로부터, 등록, 인증 및 탈퇴 요청중 어느 하나에 해당하는 사용자 요청에 따른 등록데이터를 수신하는 단계;
(b) 상기 중계서버로, 사용자 아이디, 난수 및 이들의 해쉬값을 전송하는 단계;
(c) 사용자단말기로부터 상기 사용자 요청에 따른 인증정보를 수신하는 단계;
(d) 상기 사용자 아이디에 해당하는 공개키 요청을 상기 중계서버로 송신하는 단계;
(e) 상기 중계서버로부터, 상기 사용자 아이디에 해당하는 공개키를 수신하는 단계;
(f) 상기 인증정보에 대해서 상기 단계(e)에서 수신한 공개키를 이용하여 전자서명 검증을 하여, 검증 실패인 경우 단계(i)로 진행하고, 검증 성공인 경우 단계(g)로 진행하는 단계;
(g) 상기 인증정보 내의 사용자 아이디와 난수 데이터들을, 상기 포털서버 자신이 상기 중계서버를 통해 사용자단말기로 보낸 사용자 아이디, 난수, 이들의 해쉬 값에 해당되는 데이터와, 사용자 아이디를 기준으로 매칭시키는 단계;
(h) 상기 단계(g)에서 매칭시킨 해당 난수들이 서로 일치하지 않는 경우 검증 실패로 판단하고, 모두 일치하는 경우 검증 성공으로 판단하는 단계;
(i) 상기 단계(f)에서 전자서명 검증 실패이거나 상기 단계(h)에서 검증 실패인 경우, 해당 등록, 인증, 탈퇴 요청을 실패처리하고 상기 인증정보 내의 난수정보가 포함된 실패메시지와 사용자 아이디를 임시 저장한 후 상기 실패메시지와 사용자 아이디를 사용자단말기로 전송하고, 또는 상기 단계(f)에서 전자서명 검증 성공이고 상기 단계(h)에서 검증 성공인 경우 성공신호를 중계서버로 전송하는 단계; 및,
(j) 상기 단계(i)에서 성공신호를 중계서버로 전송한 후에, 상기 중계서버로부터 성공메시지를 수신한 경우 최종적으로 성공처리하고, 상기 중계서버로부터 실패메시지를 수신한 경우 최종적으로 실패처리하는 단계
가 실행되도록 하는 명령을 포함하는,
중계서버와 연계하여 포털 서비스를 제공하기 위한, 컴퓨터로 판독 가능한 비일시적 저장 매체에 저장된 컴퓨터 프로그램.
포털사이트 중계 서비스 제공 시스템으로서,
포털사이트를 제공하고, 청구항 26의 중계서버와 연계하여 최종적으로 사용자의 등록, 인증 및 탈퇴 처리를 수행하는 청구항 28의 포털서버; 및,
사용자단말기로부터의 등록, 인증 및 탈퇴 요청에 대한 처리를 상기 포털서버에 대하여 중계하는 역할을 수행하는 청구항 26의 중계서버
를 포함하는 포털사이트 중계 서비스 제공 시스템.
청구항 30에 있어서,
사용자단말기에 최초 로그인 화면 및, 등록, 인증 및 탈퇴 처리에 대한 최종 성공 화면 또는 최종 실패 화면을 제공하는 고객사 웹 서버
를 더 포함하는 것을 특징으로 하는 포털사이트 중계 서비스 제공 시스템.