일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- 파이썬 동시성
- play2 강좌
- Adapter 패턴
- 스칼라
- Akka
- akka 강좌
- 안드로이드 웹뷰
- 스위프트
- Play2 로 웹 개발
- play 강좌
- 블록체인
- 파이썬 강좌
- 그라파나
- 하이브리드앱
- Golang
- 스칼라 동시성
- 파이썬 머신러닝
- 플레이프레임워크
- Actor
- CORDA
- 주키퍼
- 스칼라 강좌
- hyperledger fabric
- Play2
- 엔터프라이즈 블록체인
- Hyperledger fabric gossip protocol
- 파이썬
- 파이썬 데이터분석
- 하이퍼레저 패브릭
- 이더리움
- Today
- Total
HAMA 블로그
자바와 보안을 알기위한 스터디 본문
0. 인증 / 인가 / 무결성 이란 ?
인증 (Authentication) : A 라는 사람이 그 싸이트 혹은 그 서비스를 사용할수있는가? 신원 확보 목적.
인가 (Authorization) : A 라는 사람이 서비스에서 어떤것을 할수있도록 하는가 ? ( 파일 리딩만 하게하자)
무결성 : A -> B 로 어떤 메세지를 보냈을때 그 메세지가 바뀌거나 깨지지 않음을 보장하는것.
1. 암호화 / 복호화 란 ?
암호화 : 어떤 문자열 "hello world" 를 "332XF3FX_*)3" 로 바꾸는것.
복호화 : "332XF3FX_*)3" 을 다시 "hello world" 로 환원하는것.
암호화 알고리즘에는 DES , AES 등이 있다.
JAVA AEC : http://andang72.blogspot.kr/2012/02/aes.html
암호화와 복호화를 위해서는 key (비밀키) 라는것이 필요하다.
2. 대칭형 암호화
A 와 B 라는 각각의 Peer 를 상상해보자.
각각의 컴퓨터에 동일한 key 를 복사해두고, 동일한 key 를 이용해서 암호화 / 복호화를 하는것이
대칭형 암호화이다. A,B 모두를 제어권에 두고있다면 대칭형 암호화로 충분하다.
하지만 A 는 내가 관리하는데 B 를 관리할수없을경우 B 에게 나의 비밀키를 보내야하는데
그 중간에서 탈취를 당하면 탈취한사람은 A 와 B 의 비밀 이야기를 엿들을수있게 된다.
3. 공개키 암호화 ( 비대칭형 )
공개키 암호화 (비대칭형) 방법이 대칭형과 다른것은 키를 2개 만드는것이다.
비밀키 1개에서 -> 공개키,개인키 요렇게 2개!!
개인키는 자신이 가지고 있고, 공개키를 B 에게 전달한다. 전달받은 B 는 자신의 공개키를 A에게 보낸다.
공개키로 암호화하고 개인키로 복호화한다. 암호화는 누구나 할수있지만 , 복호화는 자신밖에 못하기때문에
보안을 이룰수있다.
4. 비대칭형 / 대칭형 믹스
위의 공개키암호화는 상당히 안전하지만 , 공개키/개인키를 통한 암호화/복호화는 상당히 느리다.
따라서 처음에만 공개키로 하고 다음부터는 대칭키로 암호화/복호화를 하는 전략을 쓴다.
1 .A 는 자신의 공개키를 B에게 전달한다.
2. B 는 A의 공개키로 자신의 비밀키를 암호화해서 A에게 전달한다.
3. A 는 자신의 개인키로 B 의 비밀키를 복호화한다.
4. 공유된 B 의 비밀키로 통신한다.
이 방법은 B 가 A 의 공개키를 어떻게 진짜 A 의 공개키인지 믿을수 있나? 라는 화두를 던진다.
5. 해쉬 함수
"EWEFWFWEEFWFWEWFWE32R2FF2F" 이렇게 긴 문장을
"F3F34" 요렇게 짧게 바꾸는 작업을 말한다.
해쉬된 문장을 원래 문장으로 바꾸는건 불가능하다.
해쉬를 왜 하냐면 , 짧으면 무엇이 좋을까?
1. 암호화, 복호화 할때 시간이 단축된다.
2. 원래 문장을 전송에 사용할 필요가 없어진다. 따라서 비밀번호같은것의 노출을 피할수있다.
예를들어 비밀번호를 해쉬함수를 통해서 걸러진 문장을 DB 에 저장해두면, 진짜 비밀번호를 알수는
없지만, 동일한 비밀번호로부터 나온 결과라는것은 알수있게된다.
MD5 / SHA1 같은것을 사용한다.
6. 전자 서명
상대방의 신원을 확인하기 어려운 사이버 공간에서 서로를 알아볼 수 있도록 한 쌍의 전자서명키 (공개키+개인키)를 사용하여 자신을 증명하는 것이 전자서명의 원리입니다. 공인인증기관으로부터 인증서를 발급받아 전자계약서 등에 전자서명을 하여 계약내용을 증명합니다.단지 사이버 공간이라는 환경과 모든 처리가 전자적으로 처리된다는 것이 차이점입니다.
네이버어플리케이션 전자서명의 원리 : http://helloworld.naver.com/helloworld/textyle/744920
7. 인증서
당신과 접속해있는 사람이나 웹 사이트가 믿을 수 있는지 어떻게 판단할 수 있을까? 한 웹사이트 관리자가 있다고 가정하자. 그 사람이 당신에게 이 사이트가 믿을만하다고 (심각할 정도로) 열심히 설명했다. 당신이 그 사이트의 인증서를 설치해 주기를 바라면서 말이다. 한두번도 아니고 매번 이렇게 해야한다면 귀찮지 않겠는가?
인증서는 여러 부분으로 이루어져있다. 아래는 인증서 속에 들어있는 정보의 종류를 나타낸 것이다.
인증서 소유자의 e-mail 주소
소유자의 이름
인증서의 용도
인증서 유효기간
발행 장소
Distinguished Name (DN)
- Common Name (CN)
- 인증서 정보에 대해 서명한 사람의 디지털 ID
Public Key
해쉬(Hash)
SSL의 기본 구조는 당신이 인증서를 서명한 사람을 신뢰한다면, 서명된 인증서도 신뢰할 수 있다는 것이다. 이것은 마치 트리(Tree)와 같은 구조를 이루면서 인증서끼리 서명하게 된다. 그러면 최상위 인증서는? 이 인증서를 발행한 기관을 Root Certification Authority(줄여서 Root CA)라고 부르며, 유명한 인증 기관(역주:Verisign, Thawte, Entrust, etc)의 Root CA 인증서는 웹브라우저에 기본적으로 설치되어 있다. 이러한 인증 기관은 자신들이 서명한 인증서들을 관리할 뿐만 아니라 철회 인증서(Revoked Certificate)들도 관리하고 있다. 그러면 Root CA의 인증서는 누가 서명을 했을까? 모든 Root CA 인증서는 자체 서명(Self Signed)되어 있다.
8. SSL
SSL 은 위의 4번과 동일하다. 다만 추가된것은 공개키를 인증해주는 과정이 추가되었다.
A의 공개키를 CA 기관에 전자서명을 받아서 인증서를 받은후에 (CA 에서는 자신의 개인키로 암호화함) B에게 보내준다. B는 자신의 컴퓨터에 미리 존재하는 (브라우저안에도 있음) CA의
공개키로 인증서를 확인하여, A의 공개키를 얻는다.
HTTPS 에 사용된다.
9. JCA
가) 전자 서명과 메시지 다이제스트 같은 기능에 대한 일반적인 API 제공
나) 주요 클래스들
① MessageDigest
② Signature
③ KeyPaireGenerator
④ KeyFactory
⑤ CertificateFactory
⑥ KeyStore
⑦ AlgorithmParameters
⑧ AlgorithmParameterGenerator
⑨ SecureRandom
다) 암호 서비스 제공자 Sun Provider(Java 2 기준, sun.security.provider.Sun)
① MD5 메시지 다이제스트
② SHA-1 메시지 다이제스트
③ DSA 전자 서명 사인과 검증
④ DSA 키 쌍 생성
⑤ DSA 키 변환
⑥ X.509 인증서 생성
⑦ Proprietary keystore 구현
⑧ DSA 알고리즘 매개변수
⑨ DSA 알고리즘 매개변수 생성
라) 암호 서비스 제공자 RSAJAC provider(com.sun.rsajca.Provider)
① RSA 키 쌍 생성
② RSA 키 변환
10) JCE
가) 주요 클래스와 인터페이스
① Cipher
② KeyAgreement
③ KeyGenerator
④ Mac
⑤ SecretKey
⑥ SecretKeyFactory
나) JCE 접근
KeyGenerator keyGenerator = KeyGenerator.getInstance(“Blowfish”);
Key key = keyGenerator.generatorKey();
Cipher cipher = Cipher.getInstance(“Blowfish/ECB/PKCS5Padding”);
cipher.init(Cipher.ENCRYPT_MODE, key);
byte[] cipherText = cipher.doFinal(myData);
다) JCE 설치
이름
BouncyCastle
URL
http://www.bouncycastle.org
12. JSSE
13. JAAS
http://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/JAASRefGuide.html
14. Java SASL
https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html
15. Java GSS-API
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/index.html
16. 커버로스
http://publib.boulder.ibm.com/html/as400/v5r1/ic2986/info/rzakh/rzakha06.htm
17. LDAP
http://jabcholove.tistory.com/89
18. 스프링에서의 보안
http://www.slideshare.net/madvirus/ss-36809454
19. AngularJS 에서의 보안
https://www.youtube.com/watch?v=18ifoT-Id54
20. 하둡에서의 보안
http://www.slideshare.net/oom65/hadoop-security-architecture
'보안' 카테고리의 다른 글
SSH 인사이드 (0) | 2016.06.09 |
---|---|
HTTP 다이제스트 엑세스인증 (0) | 2015.09.20 |
HTTP 기본인증 (Basic authentication) (0) | 2015.09.20 |
HTTP 세션을 이용한 인증 (0) | 2015.06.04 |
HTTPS 설정 및 사설인증서 관련 글들 (0) | 2015.06.04 |