PPAP를 대체하는 서비스를 시도해 보았지만 아직 조금 모자랐다

PPAP란?
PPAP는
(P) 암호 ZIP 파일을 보내고
(P) 암호 보내기
(A) 암호화
(P) 프로토콜
탭
한마디로 일반적인 인터넷 회선을 이용해 비밀번호 ZIP 파일을 도청했다면 이후 보낸 비밀번호도 도청될 가능성이 높아 의미가 없다.


지난해 2020년 11월에도 내각부 등이 운용을 금지하는 등 사회적인 문제가 제기됐고, 최근 이를 운용하는 회사와 조직은 폐지 등의 대응에 직면했다.
일부는 클라우드 서비스를 이용해 클라우드 서버에 저장된 데이터의 URL 링크를 상대방에게 알리는 교환 방법 등으로 바꿨지만, 결국'URL 알리기'에서 도청당하면 끝이다.
왜 대체품이 생기지 않습니까?
이런 상황에서는 대략 두 가지 이유밖에 없다.

운용이 번거롭다

제작하기 힘들어

따라서 우리는 PPAP가 이 세계에서 여전히 성행하고 있으며 비밀번호 ZIP를 대체하여 더욱 편리하게 활용되는 서비스도 나타나지 않을 것이라고 상상할 수 있다.
하지만 도전해 보고 싶어요.대체 시스템으로는 서비스를 고려할 수 없을 것 같아서 시험해 봤어요.
공개 키 사용 방법
파일 등 데이터 교환을 공고히 하기 위해서는 이른바 공통된 '암호' 로 이루어진 공용 키 암호화 방식이 아니라 서로 키를 교환하는 공개 키 암호화 방식이 좋다고 생각합니다.
키는 암호 키와 암호 해독 키 쌍(쌍)으로 사용할 수 있으며, 한 쪽 키로는 다른 쪽 키를 생성할 수 없습니다.'암호화 키'는 암호화만 가능하고'암호화 키'는 암호화만 가능하다는 뜻이다.

발송자가 로컬에서 '키 맞추기' 를 생성하여 암호화 키 (공개 키) 를 상대방에게만 전달하면 암호화 키 (기밀 키) 를 곁에 둘 수 있다.암호 키에서 암호화 키를 생성하는 것은 사실상 불가능하기 때문에 도청자가 통신 경로에서 암호 키를 얻는 것도 무의미하다.

그리고 로컬에서 한 번도 나오지 않은 암호화 키 (개인 키) 로 암호화 파일을 받은 다음 복호화합니다.

간단하네.
이 중에서도 오랜 기간 사용돼 편리하고 보안이 입증된 RSA 알고리즘을 사용하는 것이 좋다.
대량의 질인수 분해가 어려워 안전성을 얻었기 때문에 이 알고리즘의 공공 키와 개인 키는 큰 (617비트) 소수의 함수이다.밀문과 공개 키에서 원시 데이터를 복호화하는 것은 이 두 소수의 곱셈에 대해 질인수 분해를 하는 것과 같다.
사실 이 공개 키 암호화 방식을 사용한 RSA의 암호화 소프트웨어는 졸작서류 가방이 있다.
다만 사용자로부터 오류 보고와 요구를 받기만 하면 공개 키 암호화 방식은 사용자가 사용하는 느낌이 거의 없다.
그건 귀찮아서 그런가 봐요.
구체적으로는'열쇠 교환'장소겠죠.
키 교환 서비스 만들기
그럼 그 열쇠를 간단하게 교환할 수 있는 서비스를 할 수 있을 것 같아요.RSA에서 암호화 프로그래밍을 해본 경험이 있기 때문에 전용 앱도 만들 수 있을 것 같다.
그래서 실제로 해봤어요. AttacheCase.NET입니다.
AttacheCase.NET
https://attachecase.net/
우선 상기 사이트에서 발송자는 메일 주소 등 필요한 정보를 입력한다.

이렇게 하면 서버에서 응용 프로그램의 다운로드 URL을 얻을 수 있다.
다음에 그 '다운로드 URL' 을 교환하는 상대방 (수신자) 에게 전달합니다.

수신자는 그 다운로드 URL에서 전용 디코딩 애플리케이션을 다운로드한다.

그리고 수신자가 다운로드한 프로그램을 시작하고 '발송' 단추를 누르면 된다.

응용 프로그램은 자동으로 암호 키 (공개 키) 쌍과 암호 키 (비밀 키) 를 생성하고 암호 키만 생성합니다.NET로 보내면 서버는 발송자의 입력 정보에 따라'비밀번호 키(공개 키)'를 추가해 발송자에게 메일을 보낸다.
보낸 사람은 AttacheCase입니다.NET에서 보내온'암호키(공개키)'로 데이터 파일을 서류 가방(무료 소프트웨어)으로 암호화해 상대방에게 보낸다.

수신자는 보내는 암호화 파일을 전용 프로그램에 끌어다 놓으면 복호화할 수 있습니다.
응, 구축해 보았지만, 실제로 운용해 보니 수신인

다운로드 애플리케이션

어플리케이션 시작

시작 및 표시된 창의 보내기 버튼

을 누릅니다.
이 일련의 동작은 보기에 매우 간단하고 번거롭다. "왜 반드시 발송 버튼을 눌러야 합니까?"이러면 손이 멈출 수도 있어.
그러나 사이트, 앱 디자인, 발신자가 적당한 지시를 하면 이곳은 통관할 수 있다.
약점도 있어요.
사실 PPAP와 통하는 점은 있지만 이 서비스에도 약점이 있다.
다운로드 URL을 보낼 때 일반적인 네트워크라면 도청자에게 알려질 때도 있다.클라우드 서비스를 이용해 다운로드 URL을 상대방에게 전달할 때도 마찬가지다.

수신자를 사칭하여 공개 키 (암호 키) 를 먼저 보낼 수 있는 불법 경로를 사용할 수 있습니다.

하지만 AttacheCase는NET에서는 공개 키(암호키)의 첨부파일은 한 번만 보낼 수 있기 때문에 수신자가 발송 버튼을 누르고 발송에 성공하면 전화 등 다른 수단을 이용해 암호화된 파일을 받을 수 있는 상태인지 확인하면 안전성이 높아진다.
또 다운로드 옵션으로는 다운로드 횟수 제한과 다운로드 가능 시간이 있기 때문에 설정을 통해 도청 위험성을 줄일 수 있다.
나는 이 부근에서 클라우드 서비스에서 다운로드할 때의 옵션으로 설정할 수 있는 곳이 매우 많다고 생각한다.
편리성을 취하느냐 안전성을 취하느냐
나는 결국 그렇게 될 것이라고 생각한다.
최대한 편리하게 하려면 PPAP를 미숙하게 사용하기보다는 보호되지 않은 채 파일을 메일에 직접 추가하는 것이 좋다.
보안을 추구한다면 공개 키 암호화 방식을 사용해 키 교환을 잘 한 후 파일 교환을 해야 한다.
다만, 단 한 번이나 거래가 없는 곳으로 데이터를 보내려면 그 시간이 매우 번거로워진다.그렇다면 어디서 합의를 볼 수 있을까.
키 교환 서비스를 시도해 보았지만 클라우드 서비스와 다름없다
이런 서비스AttacheCase.NET를 만들어 봤지만 최종적으로'URL 다운로드'를 알린 곳이 약점으로 작용해 클라우드 서비스에서 거의 다운로드한 것과 크게 다르지 않았다.
다만, 우리의 서비스는 계약 클라우드 서비스의 원가를 낮출 수 있다는 점을 추천할 만합니까?
공개 키 암호화 방식은 나쁘지 않지만, 아무리 머리를 쥐어짜도 편리한 서비스가 존재하지 않으니 실현하기 힘들겠죠.
누가 더 편리하고 안전한 서비스를 가지고 있는지 저에게 알려주세요!