6일차, DES 암호화 과정

3계층 ARP 헤더구조

케인에서 Arp poison routing
APR spoofing - arp로 사기 친다.
ARP Cache Poisoning
 
Arp spoofing 공격
1 0800
6 4 2
 
Gratuitous ARP : 정상적이지 않은 ARP들을 모아서 둔 개념적 용어
정상적이지 않은 값이 들어가는 것들을 gratuitous ARP라고 부른다.
 
# IP충돌 확인.(아이피 쫑) : gratuitous의 바른 용도
부팅이 되는 놈이 소스IP에 자기꺼 1.1.1.1 목적지에 1.1.1.1로 보낸다.
그러면 미리 쓰고 있던 놈이 브로드케스트를 날린다.
그럼 켜있던 놈이 자기 거라고 광고한다.
그러면 부팅하던 놈이 gratuitous  ARP로 알아온 값을 참고해서 충돌 시 0.0.0.0으로 입력한다.
 
1)DNS spoofing

UDP의 패킷구조

   

   

#checksum

내가 UDP를 쓸지 TCP를 쓸지는 프로그래머가 소스에 대고 결정하는 것이다. 개발자가 checksum을 사용하지 않게 할 수도 있다. 안 쓰면 무의미한 값으로 채운다.(abcd..)

   

#total length

 UDP는 무조건 8byte
어플리케이션이 100byte주면 108byte
1000이오면 1008 등 total length에 적어 보낸다.
스위치에서 빨리 처리하라고 적음.
   

TFTP (UDP69번)로 1000byte보낼 시

빈 것중 1500이상 아무거나	69번 포트
1008	xxxxx

 

사설망 설정

211.48.41.131

내부 네트워크 설정에서 내부 IP 주소 설정을 마음대로 바꿀 수 있다.

브릿지 - guest os 입장에서 볼 때 VM들은 모두 1계층 hub이다.
Bridge VM0은 실제 로컬 영역 연결이다.
 
1.0.0.0/8로해서 1600만대를 쓸 수도 있다.
 
1. 127.0.0.1/ tcp/ip인식하는지 보고
2. 자기 아이피
3. 게이트웨이
4. 인근장비

암호화(대칭키)

네이버는 조각으로 ID/ pw를 나눴다.

DES -> 슈퍼컴으로 3분 후, 16라운드
[key] | xxxx 로 x o r
AES -> 린다(advance encap )
SEED란 알고리즘을 KISA가 냈다.

Key 1100 ( A -> B) , key 1101(B->C)  (비공개)
알고리즘 DES (공개)
 
암호문을 새로 만들면 보안은 좋으나 복호화가 어렵다.
보안적인 측면보다. Trade off(가성비)를 생각해야 한다.
사용자는 내 키가 제삼자에게  보낼때 보호 받아야 한다.

대칭키(=비밀키,싱글키)!!!

대칭키의 보안이슈? 내 몸에서 생성된 대칭키를 어떻게 안전하게 상대방에게 전달할 것인가

 

비대칭키!! 1976년에 생김(=공개키방식)

공개키를 이용하여 생성된 암호문은 사설키로 풀고 사설키로 이용하여 생성된 암호문은 공개키로 푼다. 키는 처음 만들어져서 나누어진다.(오직 A의 공개키로 A의 사설키를 푼다) 공개키는 공개되어도 된다. A가 먼저 자기키로 [메시지]를 암호화하고 B의 공개키로 A의 키를 암호화한다. H-H.공/H.사./A.공/B.공개키만 받을 수 있다.

   

   

1)맹점: 해커가 중간에 요청을 가로채고 자기 공개키를 보내서 자기걸로 보내서 자기키로
암호화하도록 한다.
: 해커가 자기 공개키로 응답함
 
2)맹점: 해커가 대칭키를 바꿔서 보낸다.
: 사용자인증 ?(A가 보낸건지 모름)
: 메시지 무결성?(변조가 되면 깨진거)

키 전송에 따른 맹점 3가지

송신자 - B의 공개키인가? (인증서로 해결)

수신자 - 사용자인증&부인방지 (송신자 사설키) - 실제 데이터에 대한 변조를 확인하지 못한다.(Hash 알고리즘)

내 이름이지만 오히려 다른 사람이 더 많이씀
카드사의 보안메일.. 주민번호 7자리로 암호화함.
공개키를 알고있더라도 사설키를 유추할 수는 없다.

   

최초에는 안전하게 최초 키 전달이 이루어지면 이 키로 암호화하여 보내진다.

1. 공개키,개인키로 키전달.
2. 키가 공유되었다.(대칭키 전달)

 

대칭key문제점

키 전송에 따른 맹점 3가지

송신자 - B의 공개키인가? (인증서로 해결)

수신자 - 사용자인증&부인방지 (송신자 사설키)         - 실제 데이터에 대한 변조를 확인하지 못한다.(Hash 알고리즘)

해결방법 : hash

   

실습

   

 

16진수의 값이 32개 * 4 // 128bit

   

Hash의 특징

1. One way(단방향/일방향)

   해시값으로 원문을 못 알아낸다.
   바꼈다는 사실만 알 수 있다.
   복호화가 필요없다.
   Input 사이즈와 달리 output은 동일하다.(128bit) 2진수가 128개를 32개로 16진수로 보여준다.
   Ex)믹서기

   SHA-1은 160bit이다.(무조건 변하지 않는다.)

      

ABE.exe의 해쉬값이 virus.exe와 일치하면 잡아낸다. 내용을 다 보지 않고도 빠르게 읽어낸다.

   

1. 충돌에 강하다.(collision free)

   원문이 동일하면 그에 대한 해쉬값도 동일하다.
    
   암호문으로는 변조여부를 확인하지 못하므로 해쉬로 암호를 다시깬다.
   해쉬는 지문으로 많이 예를 든다.
   Sha-1 =>160bit , sha-5 =>256

 

Md5sum -c 옵션으로 확인했을 때, 추가한 것이 없는데

• Type test.md5 로 확인하니까 내용이 달라진 것을 확인했다.
• 

   

## MD5의 특징
백업의 중요성과 연계된다.
고정된 아웃풋을 가진다.(128bit)
Collisionfree(환경이 달라져도 내용이 같다면 그대로다)
 
 
• Collision Free
M:M' => 1:1관계
 
수신자가 메시지변경여부와 사용자 인증여부를 증명하는 방법

 

Data에 대한 해쉬값을 미리 만든다.
Sha-1은 160bit이다.
송신자 사설키로 만들어 보낸 데이터의 해쉬값을 비교한다.(해커는 똥이라고 생각한다)
수신자에게 받은 공개키로 대칭키를 암호화 한다.
 
해커가 봐봐야 디지털 서명값(해쉬값)은 필요없다.
디지털서명값이 풀리자마자 A가 만든건 신뢰된다.(A의 사설키로 암호화하기에)
 
EFS(테스트 계정으로 암호화하면 admin으로 접근이 안된다) 암호화를 테스트라는 계정이 대칭키를 만들고 그 대칭키로 파일을 만들고, 대칭키를 테스트의 공개키로 보관한다.
운영체제가 사설키를 접근하지 못하도록 한다.
그래서, ACL로 준 권한보다 [암호]로 만든게 더 좋다.
 
암호화는 언젠가 복호화된다.
강력한 암호화는 복호화에 오랜시간이 걸린다.

암호화(비대칭키)

대칭키에 비해서 느리다.
TCP, UDP의 비교와 비슷.