HTTPS 기반에 비대칭키 암/복호화 무의미한 행동일까요? 정보
HTTPS 기반에 비대칭키 암/복호화 무의미한 행동일까요?본문
안녕하세요.
네이티브앱 <-> 서버 간에 중요 데이터를 주고받아야하는 상황인데요.
해당 서버는 유료 코모도기반으로 sha256rsa 로 작동됩니다.
이그나이터와 그누보드 소스에 탑재할예정인데요.
암호화를 알아보니
대칭키는 같은키를 앱,서버 모두 같이 같고있어야하고 ,
(대칭키는 프라이빗 변수에 상수값으로 담아놓고 서버에 요청할때만 파라미터에 셋팅)
비대칭키는 앱(공개키) , 서버(비밀키) 방식으로 진행되야한다고 본것같은데요.
향후 다른서버에도 유료코모도 HTTPS 를 탑재할 예정입니다.
어차피 HTTPS가 SHA256으로 한번 감싸져서 전달되는거라면..
앱에서 그냥 POST방식으로 암호화처리하지않고 전달하는것도 나쁘지않겠다 하는생각도 드는데요.
만약 HTTPS는 베이스로 깔고 별도로 암/복호화 처리를 또 수행하는것과.. 그냥 HTTPS에 보안을 의존하는것과.. 보안측면에서 많은 차이가있을까요?
별차이도없으면서 같은일을 두번식 처리하는것은 너무 비효율적인것같고..
그래서 드는생각이.. HTTPS 는 기본적으로 가되..
앱에서 서버로 자료를 전달하기전에 서버에서 키를 그때마다 생성해서(AES256)
별도의 암호화 테이블에 멤버 = 생성키로 한행을 넣어서 보관하고 , 생성된 키를 앱에 전달하여
그키와 입력폼데이터를 파라미터에 담아서 서버에 요청하면..
서버에서 암호화테이블에 멤버로 쿼리해서 키와 앱에서 받은 키를 대조해서
같으면 데이터 신뢰로 판단하고 나머지를 진행하고 , 불일치하면 신뢰없으로 경고를 반환하는쪽도
괜찮지싶은데..
제가 말씀드린방식은 서버에선 별도의 고정키를 같고있지않은상태로 , 그냥 멤버=생성키 방식으로
테이블에 보관했다가 쿼리해서 신뢰여부만 따지는거라..
암호화를 잘몰르니 어떠방식이 효율적인지 잘몰르겠습니다.
머리만 아프네요.
1. HTTPS에 보안을 다 맡기고 그냥 암호화없이 파라미터를 앱에서 서버로 전달한다.
2. HTTPS는 기본으로하되 대칭/비대칭/멤버=생성키 3개 케이스중 하나를 택해서 암호화처리한다.
여러분께서는 어떤것이 맘에드시는지요?
늦은밤 읽어주셔서감사합니다.
0
댓글 4개
그리고 대칭/비대칭키는 사용하는 방식이 다릅니다. 대칭만 사용된다든지 혹은 비대칭만 사용한다든지 하지 않아요. 대칭키는 AES와 같은 암호화/복호화 라이브러리에서 사용하는 것으로 클라이언트 및 서버가 같은 키를 가지고 있어야 하는데 키 전송에 문제가 발생합니다. 중간에 해커가 키를 가로채버리면 암호화된 문장을 해독할 수 있게 됩니다. 그래서 나온게 RSA와 같은 공개키 방식을 이용하는 암호화가 나온 겁니다.
RSA와 같은 공개키 방식은 수학적으로 계산이 어려운 것을 이용해 사용되기 때문에 장문의 문장을 사용할 수 없고 사용하려면 중간 중간을 끊어서 사용해야 합니다. 따라서 공개키방식은 단지 키 전송에만 사용합니다. 즉 서버에서 RSA로 AES에서 사용할 키를 전송해주고 전송받은 키로 클라이언트에서 암호화하거나, 클라이언트에서 AES로 암호화를 진행하고 암호화 키를 RSA로 공개키 암호화하는 방식을 사용하는 거죠. 그런데 이 시스템을 https에서 사용하고 있으므로 https하나면 족합니다. 다만 https 인증서를 제공하는 곳이 안전하다고 인증된 곳이어야 합니다. 그렇지 않으면 https는 사실 무의미한 것이 될 겁니다. 특히 중국에서 제공하는 인증서는 주의가 필요합니다. 보안은 이쪽 업계에서는 기본으로 삼아야 할 내용이기에 조금 설명을 했습니다.
정말 대단한 정보를 얻어서 너무 기쁩니다.
서버/클라에 대한 암호사용법을 알려주시니 지식스킬이 올라가는 느낌이드네요.
보안은.. 인증된 유료코모도 HTTPS (SHA256) 하나면 해결이 되는상황인것같군요..
만약 HTTPS 사용상황이 아닐경우는..
1. 앱이 글쓰기전에 서버요청
2. 서버에서 RSA로 AES256키를 생성하여 암호테이블에 멤버=AES256값 인서트해놓고 , AES256 반환
3. 결과값으로 받은 AES256을 가지고 AES256키, 제목, 내용, 계정 같은 파라미터를 담아 다시 write.php에 요청.
4. 서버에서 POST로 받은 AES256과 암호화테이블의 멤버로 쿼리해서 얻은 AES256키를 대조하여 같은지 진위여부파악.
5. 여부파악후 맞지않는다면 경고로 반환 , 맞다면 POST 파라미터들을 처리.
말씀하신것을 토대로 한번 작성해봤습니다.
여건만 된다면 MYSQL 에서 데이터 자동삭제 기능을 넣어서 하루~이틀 경과하면 삭제되게끔해서
사용자가 AES키를 얻고나서 1시간이 지나서도 서버에 데이터전달을 안할때는 앱에서 보관중인 AES키는 유효하지않은 키로 하는것도 한방법이겠네요?
그리고 만약 앱에 자체적으로 Priavte 변수로 AES256키를 상수화시켜서 1번과정을 스킵하면
1~2번 과정을 스킵할수있으니 나름 좋을것같긴한데.. 메모리 해킹이 일어나면 AES256이 노출되는
문제가 있고.. 스튜디오로 AES256키를 변경시켜서 업데이트하기에는 여러모로 후처리가 좋지않겠군요..
차라리 글쓰기 시도할때마다 AES256키를 받을게 아니라
앱이 부팅되거나 , 백그라운드->포그라운드로 전환되거나 , 이런 이벤트가있을때마다
동기화요청해서 AES256키를 갱신하는것도 괜찮겠네요. 하루종일 앱을 가지고 놀진않을테니..
아참. RSA기반의 비밀키는 서버에 값을 고정시켜서 서비스한다친다면.. RAS의 공개키는
언제 주면되는걸까요? 어차피 공개키는 하나이고 노출되도 문제가없으므로
앱이 액티브될때 공개키를 다운받아 놓으면되겠지요?
AES256이 아직 뚫린사례가 없다면..
앱이 처음부팅할때 한번만 동기화해서 받아놓고 계속 그걸로 쓰는것도 괜찮겠네요.
웹이든 네이티브앱이든 항상 보안문제에 대해서 걱정하면서 별다른 조치를 안했지만..
이번일로 많은 정보를 얻어가며 큰 깨달음을 얻었습니다.
복많이 받으시고요. 언젠가 돈이 좀 되면 의뢰로 한번 점검부탁드리고싶네요. 수고하세요!
