2012-06-11 2 views
3

컴파일 된 java 파일 내부에서 문자열을 암호화 할 수 있는지 알고 싶습니다. 예를 들어, 내가 대칭 키를 사용하여 zip 파일을 디코딩 할 필요가 나는 개인 일정에 자바 클래스에서 해당 키를 저장해야합니다바이트 코드 역 공학에 대한 자바 상수

private static final String ZIP_PASSW="secret" 

하지만 난 간단한 반전 바이트 코드가 표시되는지 싶지 않아 원시 암호 ... 그것을 피하기 위해 존재한다고 생각합니까?

고맙습니다.

추신 : 나는 왜 S.O. 내 질문에이 표준이 없으면 표준에 맞지 않는다고 말했습니다.

+0

나는 그 좋은 질문을하고 어떤 경우에는 비동기 적 암호 (모든 사람이 그 전문 용어로 소리내어 말하기 때문에)가 그 문제에 도움이되지 않을 것이라고 생각한다. 예 : 사용자 지정 암호를 일반 텍스트로 검색 할 수 있어야하지만 db의 일반 텍스트로 저장하지 않으려는 응용 프로그램 데이터베이스에 저장하려는 경우. 따라서 애플리케이션이 암호화하고 해독 할 수 있어야합니다 => 제공해야 할 키와 동일한 문제 (비동기 암호화를위한 두 개의 키)가 있습니다. 아무리 당신이 싱크로네이즈를 AES로 사용하든 그렇지 않든간에. – tObi

답변

2

대칭 키를 사용하여 zip 파일을 디코딩해야한다고 말하면 은 분명히입니다. 암호를 일반 텍스트로 저장하는 방법이나 인코딩 방법에 대한 세부적인 생각보다는 전체 아키텍처를 살펴볼 필요가 있습니다. 예를 들어 코드가 보안 웹 서비스를 호출하여 키를 저장하지 않고 저장할 수 있습니다. 분명히 당신이 원하는 것을보다 잘 이해하지 못한다면 실행 가능한 대안을 제시하는 것이 어렵지만, 당신이 묘사하고있는 것은 적절하게 보안을 유지하기가 어려울 것입니다. 이것은 무명으로 안전 할 것이지만 강하지는 않을 것입니다 당신의 열쇠를 찾기로 결심 한 누군가와

당신이해야 할 일에 충분히 안전하지 않다면, 가장 표준적인 응답은 아마도 대칭 암호화를 사용하기보다는 일종의 PGP 키 교환을 통합 할 것입니다.

+0

사용자가 외부 메모리의 모든 데이터를 백업 할 수 있도록 DB 덤프 파일을 만들어야합니다. 하지만 평범한 파일을 원하지 않습니다. – Tobia

+0

사용자가 공개 키를 업로드하면 데이터를 암호화 할 수 있지만 개인 키가 없으면 암호를 해독 할 수 없습니다. 그들은 그것을 암호화하여 다운로드하여 여가 시간에 해독 할 수 있습니다. – glenatron

+1

asiymetric 키로 내 문제를 해결할 수있는 이유를 이해할 수 없습니다 ... 내 개인 키를 내 코드에 저장해야합니까, 아니면 잘못 되었습니까? – Tobia

0

이미 암호화 된 암호는 저장하는 것이 어떻습니까?

0

아니요. 암호화 된 암호를 저장하면 어떤 시점에서 암호를 해독해야하며 크래커가 코드를 분해하고 알고리즘을 찾아 암호를 알아낼 수 있습니다.

1

당신이 할 수있는 최선은 액세스하기가 좀 더 어렵게 만드는 것입니다. 암호화 된 문자열은 코드에 저장된 암호를 사용하여 해독 할 수 있습니다. 암호를 숨기위한 조치를 취할 수도 있지만 개인 상수를 사용하는 것은 그러한 조치 중 하나가 아닙니다.

4

실제 해커가 암호를 해독 할 수는 있지만 암호를 String 리터럴로 저장하지 않으면 암호 해독이 어려워 질 수 있습니다. 당신은 사용할 수 있습니다

private static final String KEY = new String(new char[]{'s', 'e', 'c', 'r', 'e', 't'}); 

이 바이트 코드가 발생합니다 :

javap -c -v TestObfuscate 

static {}; 
    Code: 
    Stack=6, Locals=0, Args_size=0 
    0: new #10; //class java/lang/String 
    3: dup 
    4: bipush 6 
    6: newarray char 
    8: dup 
    9: iconst_0 
    10: bipush 115 
    12: castore 
    13: dup 
    14: iconst_1 
    15: bipush 101 
    17: castore 
    18: dup 
    19: iconst_2 
    20: bipush 99 
    22: castore 
    23: dup 
    24: iconst_3 
    25: bipush 114 
    27: castore 
    28: dup 
    29: iconst_4 
    30: bipush 101 
    32: castore 
    33: dup 
    34: iconst_5 
    35: bipush 116 
    37: castore 
    38: invokespecial #12; //Method java/lang/String."<init>":([C)V 
    41: putstatic #16; //Field KEY:Ljava/lang/String; 
    44: return 

반면
private static final String ZIP_PASSW="secret" 

반환

Constant pool: 
const #8 = String #9; // secret 

내가 전화하지 않았다 유의하시기 바랍니다 상수 PASSWORD r ZIP_PASSW (문자열이 공용 인 경우 중요 함).

ProGuard과 같은 난독 화 도구를 사용할 수도 있습니다.

+0

공개 문자열은별로 좋은 생각이 아닙니다 :-) 나는이 솔루션을 좋아합니다. :-) 그게 안전하지는 않지만, 뭔가 이상합니다. – Tobia

+1

jad는 여전히 이것을 다음과 같이 디 컴파일합니다.'private static 마지막 문자열 KEY = 새로운 문자열 (새로운 char [] { ','e ','c ','r ','e ','t '});' – maksimov

+0

@maksimov 네 말이 맞아. 명백한 ... 대부분의 decompilers에 대한 –

3

코드에 키를 저장하면 리버스 엔지니어링을 통해 항상 검색 할 수 있습니다. 또한 컴파일 전후에 키를 저장하더라도 문제가되지 않습니다.

프로그램을 리버스 엔지니어링하지 않고도 (암호화되지 않은) 모든 종류의 키를 전달할 수있는 방법은 없습니다. 이것이 비대칭 암호화가 처음부터 발명 된 이유입니다.

대칭 암호화 사용을 주장하는 경우 키를 응용 프로그램 외부 (예 : 텍스트 파일)에 저장하고 안전한 채널의 파일을 프로그램 사용자에게 제공해야합니다. (누가 원하는 방식으로 키를 사용할 수 있는지).

이것이 원하지 않으면 비대칭 암호화 기술을 조사해야합니다.